>Description:
        I have just installed mysql 3.23.33 on my system and was
        testing the mysqldump command as per the manual. I have not
        created any new databases. When I run mysqldump with the --tab
        option, the *.txt files created are world read/writable.
        This is a serious security issue that world writeable files are
        created (especially user.txt when dumping mysql).
        I have traced this back to line 935 of mysqldump.c where the
        SQL string with the INTO OUTFILE is created.

>How-To-Repeat:
        I have followed the setup examples as per the documentation:
        * as root, create the 'mysql' user and group
        * as root chown ownership & group to 'mysql' for the mysql
        installation
        * as mysql user, create initial databases:
        mysql@lager% ./bin/mysql_install_db 
        * copied mysql.server startup script to /etc/init.d. Added a
        bit more security so that safe_mysqld now has the --user=mysql
        option.  (I would have liked to use the --secure &
        --safe-show-database options as described in the manual, but
        they are not supported by this version of mysqld.)
        * start mysqld by running /etc/init.d/mysql.server as *root*:
        root@lager# /etc/init.d/mysql.server start
        Starting mysqld daemon with databases from /usr/local/pkgs/mysql-3.23.33/var

        mysql@lager% ps -ef|grep mysqld
          root 17014     1  0 22:54:34 pts/3    0:00 /bin/sh 
/usr/local/pkgs/mysql-3.23.33/bin/safe_mysqld --user=mysql --datadir=/u
          mysql 17031 17014  0 22:54:34 pts/3    0:00 
/usr/local/pkgs/mysql-3.23.33/libexec/mysqld --basedir=/usr/local/pkgs/mysql-3.

        * Note that the shell umask for these users is sensible:
        mysql@lager% umask
        022
        root@lager# umask
        002

        * I select from a table and write the results to a file:
        mysql@lager% ./bin/mysql -u root -p mysql
        Enter password: ********
        mysql> select * from user into outfile '/tmp/umask.test1';
        Query OK, 4 rows affected (0.00 sec)
        mysql> quit
        Bye
        mysql@lager% ls -l /tmp/umask.test1 
        -rw-rw-rw-   1 mysql    mysql        192 Mar  8 23:26 /tmp/umask.test1

        * Now I set my environment variable of UMASK to 022 for both
        the root and mysql user and restart the daemon.
        mysql@lager% UMASK=384 ; export UMASK
        root@lager% UMASK=384 ; export UMASK
        root@lager# /etc/init.d/mysql.server start
        (note that I have also tried values of 022 for UMASK)

        * I select from a table and write the results to a file:
        mysql@lager% ./bin/mysql -u root -p mysql
        Enter password: ********
        mysql> select * from user into outfile '/tmp/umask.test2';
        Query OK, 4 rows affected (0.00 sec)
        mysql> quit
        Bye
        mysql@lager% ls -l /tmp/umask.test2 
        -rw-rw-rw-   1 mysql    mysql        192 Mar  8 23:30 /tmp/umask.test2

        * If the file exists with different permissions before an INTO
        OUTFILE is called, the file's permissions change to world
        read/writeable after INTO OUTFILE is called.
        * Note - I have also seen this behaviour with MySQL version 3.22.32

>Fix:
        The quick fix I can think of is to change permissions on the
        dump directory so no-one else can read it. Also, immediately
        after running the dump, chmod the files back to something a bit
        better. But these are just workarounds and only applies to
        dumps and not any other writing to files.

        The problem may lie in libmysql/my_open.c where the open is
        called.  Otherwise, it looks like the code issue may be when
        the umask is set in line 95 of libmysql/my_init.c. The logic
        tests for the UMASK environment variable to be there and sets
        my_umask to octal version of the env var or 0600. Very
        sensible, but what happens if UMASK environmrnt variable is not
        defined at all?  This code does nothing. Not that the umask is
        being set correctly anyway.

        Either way, I am way out of my depth with C code. I wouldn't
        really know what to do from here.

>Submitter-Id:  <submitter ID>
>Originator:    John Warburton
>Organization:  Uniq Advances
>MySQL support: none
>Synopsis:      INTO OUTFILE 'filename' creates world writeable files
>Severity:      serious
>Priority:      medium
>Category:      mysql
>Class:         sw-bug
>Release:       mysql-3.23.33 (Source distribution)

>Environment:
        
System: SunOS lager 5.7 Generic_106541-10 sun4u sparc SUNW,Ultra-5_10
Architecture: sun4

Some paths:  /usr/local/bin/perl /usr/ccs/bin/make /usr/local/bin/gcc
GCC: Reading specs from 
/usr/local/pkgs/gcc-2.95.2-SunOS5.7/lib/gcc-lib/sparc-sun-solaris2.7/2.95.2/specs
gcc version 2.95.2 19991024 (release)
Compilation info: CC='gcc'  CFLAGS=''  CXX='gcc'  CXXFLAGS=''  LDFLAGS=''
LIBC: 
-rw-r--r--   1 bin      bin      1696732 Apr 27  2000 /lib/libc.a
lrwxrwxrwx   1 root     root          11 May  6  2000 /lib/libc.so -> ./libc.so.1
-rwxr-xr-x   1 bin      bin      1115336 Apr 27  2000 /lib/libc.so.1
-rw-r--r--   1 bin      bin      1696732 Apr 27  2000 /usr/lib/libc.a
lrwxrwxrwx   1 root     root          11 May  6  2000 /usr/lib/libc.so -> ./libc.so.1
-rwxr-xr-x   1 bin      bin      1115336 Apr 27  2000 /usr/lib/libc.so.1
Configure command: ./configure  --with-unix-socket-path=/var/tmp/mysql.sock 
--with-low-memory --with-mit-threads=yes --without-perl --enable-thread-safe-client 
--without-berkeley-db


---------------------------------------------------------------------
Before posting, please check:
   http://www.mysql.com/manual.php   (the manual)
   http://lists.mysql.com/           (the list archive)

To request this thread, e-mail <[EMAIL PROTECTED]>
To unsubscribe, e-mail <[EMAIL PROTECTED]>
Trouble unsubscribing? Try: http://lists.mysql.com/php/unsubscribe.php

Reply via email to