Description of problem: We should consider adding skip-symbolic-links to a default [mysqld] configuration. Multiple problems with security implications were previously reported for configurations with symblic-links enabled (most of them required db user with create/drop table privileges and shell access to the database server) - see bug #445222, bug #454077, bug #543619, bug #543653 and bug #553648. Most issues are not a problem when untrusted users do not have a shell access to the DB server, but we should use a safer default. Users needing the feature can easily re-enable it via a trivial my.cnf change. Steps to Reproduce: Alternate patch specified using DATA / INDEX DIRECTORY clauses of the CREATE TABLE statement should be ignored by default and data file (.MYD, .MYI) should be created under /var/lib/mysql/<dbname>/.
I don't think comment #0 adequately describes the severity of the problems with DATA DIRECTORY and INDEX DIRECTORY. Any DB user with create table privileges can get the mysql server to operate on any path outside the data dir, subject to file permissions. It may even be possible to defeat the check against the data dir by exploiting the races in realpath with the technique from http://www.eecs.berkeley.edu/~daw/papers/races-usenix05.pdf . The server is a deputy waiting to be confused. A table created with DATA DIRECTORY (likewise INDEX DIRECTORY) is vulnerable to an attacker who has create/drop table and shell access and knows the database and table name. He does not need to know the victim's DATA DIRECTORY; he simply makes a symlink to the symlink at /var/lib/mysql/db/table.MYD, and the server will call realpath, follow both symlinks, and accept the final path because it is outside the data dir. Thus, DATA DIRECTORY is only useful on systems with empowered untrusted users if the table name (or the database name if the data dir is not world-readable) is randomized. And then the application had better not leak SQL error messages containing the table name to those users. Users with create table access but no shell access can still probe the existence of files and directories by looking at the errnos returned by CREATE TABLE. That probably wasn't what the admin intended by not giving them shell access. So thanks for setting skip-symbolic-links by default in rawhide. I just set it on my F12 system.
I presume comment #1 is not a request to change or enhance the fix that was applied in response to this bug report. Btw, upstream position on the DATA/INDEX DIRECTORY issues: http://bugs.mysql.com/bug.php?id=39277#c296884
(In reply to comment #2) > I presume comment #1 is not a request to change or enhance the fix that was > applied in response to this bug report. Correct. > Btw, upstream position on the DATA/INDEX DIRECTORY issues: > http://bugs.mysql.com/bug.php?id=39277#c296884 IMO, that's preposterous. The root cause of the vulnerability is the MySQL server accessing arbitrary paths on behalf of untrusted users. If that is indeed upstream's position, it is inconsistent with the security advice section of the manual, which makes no mention of any assumption that untrusted users do not have access to the server filesystem and, on the contrary, recommends setting skip-symbolic-links: http://dev.mysql.com/doc/refman/5.1/en/security-against-attack.html What would be the appropriate forum in which to browbeat upstream about this?
I put together a new DATA/INDEX DIRECTORY attack that exploits the race in the use of realpath(3). It is entered upstream at: http://bugs.mysql.com/bug.php?id=53748