Re: [Fedora-packaging] Setting secure-file-priv in my.cnf

[Honza Horak]

Hi Norvald,

generally, I like the idea about using secure-file-priv, but I don't 
like /var/spool very much, since even if FHS describes this one quite 
generally, it is not used that way in practice. I also don't think we 
have to use something different than /var/lib, just a new directory 
other than /var/lib/mysql could be used; something like 
/var/lib/mysql-common maybe? -- that directory would also be covered by 
the current SELinux context definition /var/lib/mysql(/.*), so daemon 
would be able to access that directory without adjusting the SELinux 
context rules.

Since this is mostly a packaging issue, I'm cc'ing also Fedora's 
packaging list to see if someone else has some better idea.

Regards,
Honza


On 02/18/2014 10:31 AM, Norvald H. Ryeng wrote:
>  Hi Honza,
>
>  We're looking at security hardening the default installation, and one
>  thing that came up was the secure-file-priv option, see
>
> https://dev.mysql.com/doc/refman/5.6/en/server-options.html#option_mysqld...
>  and
>  https://dev.mysql.com/doc/refman/5.1/en/privileges-provided.html#priv_file.
>
>  LOAD DATA, LOAD FILE() and SELECT ... INTO OUTFILE will cause the server
>  to import or export data. Since the server runs as mysql:mysql, it can
>  read from and write to /var/lib/mysql, which is not a good idea.
>  Therefore, I suggest we set secure-file-priv in my.cnf. The question is
>  where to put the directory. A directory inside /var/lib/mysql will be
>  interpreted as a new database, so that won't work.
>
>  One suggestion is /var/spool/mysql. Import and export data is not
>  exactly spool data, but it fits the description in the FHS: "/var/spool
>  contains data which is awaiting some kind of later processing. Data in
>  /var/spool represents work to be done in the future (by a program, user,
>  or administrator); often data is deleted after it has been processed."
>
>  What do you think?
>
>  We'll have to ask for an SELinux policy change for this, so I want to
>  make sure we pick the right place for this directory from the start.
>
>  Regards,
>
>  Norvald H. Ryeng