Your message dated Thu, 6 Jul 2006 14:12:48 +0200
with message-id <[EMAIL PROTECTED]>
and subject line Bug#377007: mysql-server-4.1: umask ignored
has caused the attached Bug report to be marked as done.
This means that you claim that the problem has been dealt with.
If this is not the case it is now your responsibility to reopen the
Bug report if necessary, and/or fix the problem forthwith.
(NB: If you are a system administrator and have no idea what I am
talking about this indicates a serious mail system misconfiguration
somewhere. Please contact me immediately.)
Debian bug tracking system administrator
(administrator, Debian Bugs database)
--- Begin Message ---
Package: mysql-server-4.1
Version: 4.1.15-1
Severity: grave
Tags: security
Justification: user security hole
Hello,
I just ran a query 'select into outfile' on a vanilla Sarge install as
user root with umask 027. The MySQL server itself has umask 077 in it's
start script. Nevertheless, the exported file ended up having mode 0666
instead of 0640 or 0600, as expected. I consider this a security hole
because it allows not only unwarranted read access, but also
undetectable modification of such an export file if this file is eg.
created in /tmp.
Workaround: Create a directory that allows only root and mysql access,
and export to a file into this directory.
Best,
--Toni++
-- System Information:
Debian Release: testing/unstable
APT prefers unstable
APT policy: (500, 'unstable')
Architecture: i386 (i686)
Shell: /bin/sh linked to /bin/bash
Kernel: Linux 2.4.27-2-686-smp
Locale: LANG=C, LC_CTYPE=C (charmap=ANSI_X3.4-1968)
Versions of packages mysql-server-4.1 depends on:
ii adduser 3.85 Add and remove users and groups
ii debconf [debconf 1.4.72 Debian configuration management sy
ii libc6 2.3.6-5 GNU C Library: Shared libraries an
ii libdbi-perl 1.50-2 Perl5 database interface by Tim Bu
ii libgcc1 1:4.1.0-1 GCC support library
ii libmysqlclient14 4.1.15-1 mysql database client library
ii libncurses5 5.5-1 Shared libraries for terminal hand
ii libreadline5 5.1-7 GNU readline and history libraries
ii libstdc++6 4.1.0-1 The GNU Standard C++ Library v3
ii libwrap0 7.6.dbs-9 Wietse Venema's TCP wrappers libra
ii mailx 1:8.1.2-0.20050715cvs-1 A simple mail user agent
ii mysql-client-5.0 5.0.19-3 mysql database client binaries
ii mysql-common 5.0.19-3 mysql database common files (e.g.
ii passwd 1:4.0.15-2 change and administer password and
ii perl 5.8.8-3 Larry Wall's Practical Extraction
ii psmisc 22.2-1 Utilities that use the proc filesy
ii zlib1g 1:1.2.3-11 compression library - runtime
mysql-server-4.1 recommends no packages.
--- End Message ---
--- Begin Message ---
Hi
On 2006-07-06 Toni Mueller wrote:
> On Thu, 06.07.2006 at 12:40:30 +0200, Christian Hammers <[EMAIL PROTECTED]>
> wrote:
> > IIRC this documented exactly this way.
>
> I'll check this.
http://dev.mysql.com/doc/refman/4.1/en/select.html
"Note: Any file created by INTO OUTFILE or INTO DUMPFILE is writable by all
users on the server host. The reason for this is that the MySQL server cannot
create a file that is owned by anyone other than the user under whose account
it is running. (You should never run mysqld as root for this and other
reasons.) The file thus must be world-writable so that you can manipulate its
contents."
> > mysql currently only writes with mode
> > 0666 and only in world writable directories (so that nobody expects
> > security). Reason was that mysql writes as system user mysql but wants the
> > unprivileged normal system user who runs "/usr/bin/mysql" to be able to
> > "use"
> > these files then.
>
> This "feature" even prevents you from ensuring basic integrity of the
> file written this way because you can't ensure that the file stays ok
> between the time it is created and the time you ("the owner") move it
> to a safe place.
Absolutely. But it's not intended to be used that way:
"The SELECT ... INTO OUTFILE statement is intended primarily to let you very
quickly dump a table to a text file on the server machine. If you want to
create the resulting file on some client host other than the server host, you
cannot use SELECT ... INTO OUTFILE. In that case, you should instead use a
command such as mysql -e "SELECT ..." > file_name to generate the file on
the client host."
> Also, how are you supposed to export confidential data
> from your databse, then?
As suggested in the quoting above.
The problem simply is that mysql runs as system user "mysql" and has
no power of creating a file that is writable by system user a but not
by system user b. Of course a could create a directory that has group
rights for mysql but then any other mysql user could also write
files there. So to not led users into false sense of danger they don't
even try to be secure with INTO OUTFILE. A select in a shellskript is
the preferred method.
Maybe you could ask them to write a "BIG FAT WARNING" instead of a mere "Note:"
if
you feel that these sentences are too hidden...
Anyway, I close the bug report. But thanks for reporting what seemed to be a
security
problem (mysql has had some of them :))
bye,
-christian-
--- End Message ---
