MySQL Bugs: #35090: umask applied as bitmap instead of as a mask

Bug #35090	umask applied as bitmap instead of as a mask
Submitted:	5 Mar 2008 20:15	Modified:	3 Mar 2009 13:24
Reporter:	d di (Basic Quality Contributor)	Email Updates:
Status:	Verified	Impact on me:	None
Category:	MySQL Server: General	Severity:	S3 (Non-critical)
Version:	5.0, 5.1, 6.0 BK	OS:	Any (Unix-only?)
Assigned to:		CPU Architecture:	Any
Tags:	chmod, create database, permissions, qc, umask, umask_dir

Description:
UMASK_DIR=0027 seems to cause permissions 727 (rwx-w-rwx) to be set on CREATEd DATABASE folders.

From the name "umask", I would have expected it to work like a /mask/, in effect masking group write (2) and other {r,w,x} (7), effecting a permission bitmask of 750 (rwxr-x---).

The same seems to apply to UMASK.

How to repeat:
1. Start MySQL with:
 UMASK=0027 UMASK_DIR=0027 mysqld_safe --datadir=glyp --pid-file=glof &

2. Create a database:
 mysql -e "CREATE DATABASE testmask"

3. Examine permissions:
 ls -ld /var/lib/mysql/testmask

drwx-w-rwx  2 mysql mysql 72 today /var/lib/mysql/testmask/

4. Using the standard umask tool, do the same:
 umask 0027
 mkdir somedir
 ls -ld somedir

drw-r-----  1 mysql mysql  0 today somedir

5. Notice the difference.

Suggested fix:
a) Document that UMASK does not apply as a mask.

b) Perhaps deprecate UMASK and UMASK_DIR environment variables, and if so

c) Add a my.cnf option which either does what the name implies or has a different name (fx db_create_access_bitmap, table_create_access_bitmap) -or- use the shell's umask.

Thank you for the report.

But this seems to be not MySQL issue:

$UMASK=0027 UMASK_DIR=0027  mkdir somedir2

$umask 0027

$mkdir somedir

$ ls -ld somedir*
drwxr-x---  2 ssmirnova ssmirnova 4096 Mar  5 22:32 somedir
drwxr-xr-x  2 ssmirnova ssmirnova 4096 Mar  5 22:32 somedir2

> But this seems to be not MySQL issue:
>
> $UMASK=0027 UMASK_DIR=0027  mkdir somedir2

The above test is flawed; UMASK and UMASK_DIR are used only by MySQLd, not by the shell nor mkdir.  In effect, the "somedir2" directory you create are made with the shell's default permissions.  You could just as well have typed:

-------------
# UMASK=neger UMASK_DIR=fjabbe mkdir somedir2
# ls -ld somedir2

drwxr-xr-x  2 ssmirnova ssmirnova 4096 Mar  5 22:32 somedir2
-------------

Or:

-------------
# mkdir somedir2
# ls -ld somedir2

drwxr-xr-x  2 ssmirnova ssmirnova 4096 Mar  5 22:32 somedir2
-------------

The shell does not use the MySQL UMASK/UMASK_DIR environment variables.  The mask used for the mkdir above is 0022, which is your shell's default umask.

Thank you for the correction.

Verified as described.

Notes to docs team, bug reporter, and anybody else interested:

1. What actually happens (inside the server)

This is very unfortunately named.
It's not "umask", it's "mode." ~umask, essentially.

- we have default values for modes for directories and files, my_umask_dir and my_umask (sic)

- if UMASK_DIR is set, my_umask_dir= $UMASK_DIR | 0700

- if UMASK is set, my_umask= $UMASK | 0600

- the mysqld process then sets its umask to umask(((~my_umask) & 0666)). This means: a) our default, or the user's ($UMASK | 0600) override is used here. b) we strip everything that is not read or write permissions, so this will not strip the X bit from the mode for directory creation ('eXecute' is needed to traverse a directory, but does not imply permission to list its contents); to change the mode for direction-creation, set UMASK_DIR to the desired mode.

- all calls that create names in the file-system (open(), mkdir(), ...) use the modes given for files (my_umask) and directories (my_umask_dir) where possible, supported by the OS, and not prohibited by law.

- the inno guys are the smart party and actually noticed the above, so it's handled the same way in innobase.

2. Docs Team:  What I propose short-term

Please clarify in docs to the effect of "$UMASK sets the *mode* (not umask!) for newly-created files, in a range of 0600..0666. Note that these are octal values. Similarly, $UMASK_DIR sets the *mode* (not umask!) for newly-created directories, in a range of 0700..0777. Those, again, are octal values. Please be advised that the mode a new directory will have will be a combination of $UMASK and $UMASK_DIR: for UMASK=0640 (owner can read/write, group can read, anybody else fails) and UMASK_DIR=0777, we effectively get a mode (aka 'permissions') of, bear with me, ( ~( ~0640 & 0666) & 0777 ) => ( ~( 0137 & 0666) & 0777 ) => ( ~( 0026 ) & 0777 ) => ( 0751 & 0777 ) => ( 0751 ). Are you sorry yet you asked? The 0666 is always applied internally so that $UMASK never takes away execute-permissions from $UMASK_DIR."

3. Other considerations

Once you get past the misleading variable-names, the actual processing in the server is correct. Therefore, I'm going to close as "Suggesting docs clarification / not a bug."

In the interest of the "Principle of Least Surprise" however I believe there may be merit to the suggestion of deprecating the misleading (user-visible environment variables) $UMASK and $UMASK_DIR in favour of, say, $MYSQL_FILE_MODE and $MYSQL_DIRECTORY_MODE respectively. Or, arguably, $MYSQL_FILE_UMASK and $MYSQL_DIR_UMASK with correct handling of the values given. Open WorkList item at your discretion.

Great explanation, thanks!

Changing to Documentation bug and assigning to myself for clarification in the manual. Tatjana, thanks for the information.

For the record, I think I'd have to disagree with changing this to "Docs".

Even if you have decided to leave the functionality but change the naming, this is still a bug in the source code, not in the documentation.

Updated docs:

http://dev.mysql.com/doc/refman/5.1/en/environment-variables.html

Recategorizing as Server: General for retriage, and possible reclassification as feature request of "won't fix."

I think we need to re-classify this as a feature request : having misleading names doesn't contribute to the user experience.

Depends what you mean by "contribute to the user experience".  I probably wasted a day of my life trying to figure out why MySQL Server didn't work as it was supposed to and figuring out how to coerce it.  It definitely contributed negatively to my user experience.

Bug #46315 was marked as duplicate of this one.