[debian-mysql] mysql-5.7: secure_file_priv

[Bjoern Boschman]

Hi folks,

I think we both have the same understanding of the manual :-)
My point about secure_file_priv is that users comming from mysql-5.6 or
smaller which already are using operations like 'LOAD DATA INFILE..' now
will be confused, as they might not know this new security feature.
But this could/should be handled via NEWS.Debian

Anyhow i've pushed my latest work into git with the following problem:

mysql-5.7 clean install works.

mysql-5.5 -> mysql-5.7
mysql-5.6 -> mysql-5.7
  still some failures due to changed upgradepath
  I still have not figured out how to implement a rubust mysql_upgrade
during upgrade.

@ora: I know that your documentation states that "Direct upgrades that skip
a release level (for example, upgrading directly from MySQL 5.5 to 5.7) are
not recommended or supported"
Anyhow - we still got several month before stretch will be freezed and I'd
really would like to ship mysql-5.7 already?
What do you folks think about?


Cheers
B



2016-01-04 12:26 GMT+01:00 Norvald H. Ryeng <norvald.ryeng at oracle.com>:

> Hi Björn,
>
> On Tue, 29 Dec 2015 12:22:08 +0100, Bjoern Boschman <bjoern at boschman.de>
> wrote:
>
> Hi folks,
>>
>> I've started working on a mysql-5.7 branch [0].
>>
>> While doing so I had to phase the following difference between 5.6<->5.7
>>
>> secure_file_priv [1]
>>
>> mysql-5.6 default for this setting was 'empty'  which simply disables this
>> feature.
>> mysql-5.7 builds with (what we currently do) '/var/lib/mysql-files' which
>> is based on the used INSTALL_LAYOUT=RPM [2]
>> my question is now: how shall I handle this?
>> I would not like to add  secure_file_priv= within mysqld.cnf as this would
>> deactivate this feature for customers who want to use this on purpose.
>>
>
> I think you may have misunderstood the manual. If set to empty, the server
> can read from/write to any directory. If set to NULL, import and export is
> disabled. Anything else restricts it to that directory.
>
> It's a good idea to restrict reading and writing, so I think it should be
> on by default.
>
> The default location is a result of discussions with maintainers in
> Debian, Ubuntu, Fedora/Red Hat and openSUSE/SUSE over a year ago, so I
> suggest we keep it as is and create the directory.
>
> I'm thinking of switching INSTALL_LAYOUT=STANDALONE as this seems to be the
>> only usage of this cmake flag.
>>
>> @Oracle employees: can you confirm that this has no other impact?
>>
>
> I suggest you don't change INSTALL_LAYOUT, but instead use the
> -DINSTALL_SECURE_FILE_PRIVDIR=dirname CMake option [1] if you want to
> change this value. That will leave all the other options alone.
>
> But as I said, I'd prefer to keep the default value.
>
> Regards,
>
> Norvald H. Ryeng
>
> [1]
> https://dev.mysql.com/doc/refman/5.7/en/source-configuration-options.html#option_cmake_install_secure_file_privdir
>



-- 
Mit freundlich Grüßen / Kind regards

Björn Boschman
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.alioth.debian.org/pipermail/pkg-mysql-maint/attachments/20160112/21eaff18/attachment.html>