Re: INTO OUTFILE "filename" creates world writeable files

Dear Sinisa

I think you are wrong about this not being a bug. Assuming no-one
wants to tackle the server-side RFE at this point, the bug fix I'm
suggesting is to put some error trapping in on the /client/ side,
something like this:

* don't delete file, but rename it to something unique;
* if that fails, bail out;
* if socket fails, report this, and move the file back.

After all, we only discovered this bug after we had deleted a file and
not written a new one.

Meanwhile, would it be possible to update the mysqldump documentation
so other people don't get caught by this? To:

-T, --tab=path-to-some-directory
Creates a table_name.sql file, that contains the SQL CREATE
commands, and a table_name.txt file, that contains the data,
for each give table. The format of the `.txt' file is made
according to the --fields-xxx and --lines--xxx options. Note:
This option only works if mysqldump is run on the same machine
as the mysqld daemon, and the user/group that mysqld is running
as (normally user mysql, group mysql) needs to have permission
to create/write a file at the location you specify.

Please add something like:

On some common platforms, including Solaris, this requires the
directory to be world-writeable.

Then if, like me, you're worried about the confidentiality of your data or
denial of service attacks, you'll know not to look for workarounds using
UNIX groups.

Yours
Neil Walker

PS: I'll mail re Sergei's comments in a moment.

------------- Begin Included Message -------------

Neil Walker writes:
> Dear Sinisa
>
> thanks for your reply.
>
>
> * the bug is that the file should /not/ be deleted if the new file is
> not to be written - i.e. perms should be checked first and reported
> if in error
>

I do not think that this is a good idea, as you are doing a new
backup.

This could result in entity integrity problems.

Plus it would unnecesarily complicate things. It woudl also require
some unnecessary changes on the server side which would cause
changes in the behaviour, which many customers are used to.

Not, it is NOT a bug.

> * there is a RFE too - it is not sensible to suggest anyone makes a
> 777 directory
>
> Yours
> Neil

No, but directory must be write-able by both MySQL server and client
program.

It is a duty of sysadmin to enable this.
------------- End Included Message -------------


--
MySQL Bugs Mailing List
For list archives: http://lists.mysql.com/bugs
To unsubscribe: http://lists.mysql.com/bugs?unsub=gcdmb-bugs@m.gmane.org

Re: INTO OUTFILE "filename" creates world writeable files

Neil Walker writes:
> Dear Sinisa
>
> I think you are wrong about this not being a bug. Assuming no-one
> wants to tackle the server-side RFE at this point, the bug fix I'm
> suggesting is to put some error trapping in on the /client/ side,
> something like this:
>
> * don't delete file, but rename it to something unique;
> * if that fails, bail out;
> * if socket fails, report this, and move the file back.
>
> After all, we only discovered this bug after we had deleted a file and
> not written a new one.
>
> Meanwhile, would it be possible to update the mysqldump documentation
> so other people don't get caught by this? To:
>
> -T, --tab=path-to-some-directory
> Creates a table_name.sql file, that contains the SQL CREATE
> commands, and a table_name.txt file, that contains the data,
> for each give table. The format of the `.txt' file is made
> according to the --fields-xxx and --lines--xxx options. Note:
> This option only works if mysqldump is run on the same machine
> as the mysqld daemon, and the user/group that mysqld is running
> as (normally user mysql, group mysql) needs to have permission
> to create/write a file at the location you specify.
>
> Please add something like:
>
> On some common platforms, including Solaris, this requires the
> directory to be world-writeable.
>
> Then if, like me, you're worried about the confidentiality of your data or
> denial of service attacks, you'll know not to look for workarounds using
> UNIX groups.
>
> Yours
> Neil Walker
>
> PS: I'll mail re Sergei's comments in a moment.

Hi!

Yes, we should definitely update our documentation on this and I have
already alerted our docs team.

Regarding non-deleting file, that is not a good idea, because it can
lead to a much higher confusion. It would generate so many reports of
the kind " What kind of file is this one ...".

--

Regards,

--
For technical support contracts, go to https://order.mysql.com/?ref=msmi
__ ___ ___ ____ __
/ |/ /_ __/ __/ __ \/ / Mr. Sinisa Milivojevic
/ /|_/ / // /\ \/ /_/ / /__ MySQL AB
/_/ /_/\_, /___/\___\_\___/ Fulltime Developer and Support Coordinator
<___/ www.mysql.com Larnaca, Cyprus


--
MySQL Bugs Mailing List
For list archives: http://lists.mysql.com/bugs
To unsubscribe: http://lists.mysql.com/bugs?unsub=gcdmb-bugs@m.gmane.org