MySQL Bugs: #27789: Wrong permissions of files/direcories disturb "sudo make install"

Bug #27789	Wrong permissions of files/direcories disturb "sudo make install"
Submitted:	12 Apr 2007 18:04	Modified:	25 Oct 2007 0:31
Reporter:	Hartmut Holzgraefe	Email Updates:
Status:	Closed	Impact on me:	None
Category:	MySQL Server: Installing	Severity:	S3 (Non-critical)
Version:	5.0, 5.1 (didn't check 4.1)	OS:	Linux
Assigned to:	Magnus Blåudd	CPU Architecture:	Any

Description:
The permissions are

mysql-5.0 > ls -l sql/share/
total 496
drwxrwxr-x  3 hartmut users   4096 2007-04-12 17:25 charsets
drwx------  2 hartmut users   4096 2007-04-12 17:31 czech
drwx------  2 hartmut users   4096 2007-04-12 17:31 danish
drwx------  2 hartmut users   4096 2007-04-12 17:31 dutch
drwx------  2 hartmut users   4096 2007-04-12 17:31 english
-rw-rw-r--  1 hartmut users 345938 2007-02-23 17:36 errmsg.txt
[...]

So the directories are only accessible to the current user.
root may be able to access then in some setups (local FS for example)
but not all (e.g. NFS share without root-equiv).

This leads to the paradox situation that neither the current
user nor root can perform a successfull "make install"

How to repeat:
On a file system root doesn't have special permission 
on (e.g. a NFS home directory mounted from another machine)
do:

mysql-5.0 > sudo make install

[...]
Making install in share
make[4]: Entering directory `/users/hholzgraefe/5.1/sql/share'
make[4]: stat:english/errmsg.sys: Permission denied
rm -f ../../include/mysqld_error.h
rm: cannot remove `../../include/mysqld_error.h': Permission denied
make[4]: *** [english/errmsg.sys] Error 1
make[4]: Leaving directory `/users/hholzgraefe/5.1/sql/share'
[...]

as the stat on errmsg.sys fails (due to permission problems)
make tries to re-generate it, assuming that it doesn't exist
this does of course fail, too, due to permission problems

Suggested fix:
Change permission of the sql/share/language subdirectories
from "drwx------" to "drwxrwxr-x" in the bitkeeper repositories,
all other directories in the tree have these permission settings
anyway.

Just found this to be a duplicate of Bug #19738
i'm not sure what the patches in that bug report
may have fixed but defiently not the problem at hand.

Correcting myself: these are generated directories which are not maintained within the repository.

So new suggested fix: create these directories with the correct permissions

A patch for this bug has been committed. After review, it may
be pushed to the relevant source trees for release in the next
version. You can access the patch from:

  http://lists.mysql.com/commits/24411

ChangeSet@1.2453, 2007-04-12 20:54:38+02:00, hartmut@mysql.com +1 -0
  Fixed Bug #27789 "Wrong permissions of sql/share/language directories"

changed the bugs subject as i found more not world-readable
files breaking a "sudo make install" if on a non-local FS:

  find . -not -perm +0006 | grep -v BitKeeper

shows a lot of non-world-readable files in mysql-test,
a "sudo make install" fails on these, too, as it can't
copy the test/result files that are not readable ...

ooops, 0004 is read, 0006 is read and write

  find . -not -perm +0004 | grep -v BitKeeper

is the right statement to identify these

permissions aren't wrong - they are what you asked for. Changing umask in comp_err  is not enough, it does not affect files generated during make - e.g. mysqld binary.

If your setup requires your generated files to be world-writable - set your umask appropriately.

My system umask is 0002, so only preventing world write access
to user created files, it is my_mkdir() that promotes it down
to user read/write only, and that is what my patch is supposed 
to fix.

umask 0002, without my patch: created directories not world readable, sudo install fails

umask 0002, with my patch: created directories world readable, sudo install succeeds

umask 0077, with my pacht: created directories not world readable, sudo install fails again

only in the last case the "permissions aren't wrong - they are what you asked for" argument holds, in that case i really get what i asked for. Problem is that
my_mkdir() does not only do 

  flags & ~user_umask

as system mkdir would do, but actually does 

  (flags & my_umask_dir) & ~user_umask

so overriding the users umask setting which is ok for its usual use case
from within the server but not for the user level tools, especially not
for those that are part of the build process.

By setting my_umask_dir to 0777 in comp_err.c i'm merely restoring the
system mkdir behavior as now all bits of my_umask_dir are set so that
no additional library masking of bits happens.

Ok, agree. I would never expect comp_err to modify user's umask.

Now I wonder, does this messing with umask belong to my_init() ?
I think it should be moved to mysqld.cc.

Hartmut,

Please push your patch to 5.0-maint.  I've opened bug #28043 in regards to setting mysqld's default umask values in mysqld.cc.

Thanks,

Timothy

Hartmut, putting this in my list so itäs not forgotten.

A patch for this bug has been committed. After review, it may
be pushed to the relevant source trees for release in the next
version. You can access the patch from:

  http://lists.mysql.com/commits/35006

ChangeSet@1.2484, 2007-10-05 19:55:00+02:00, msvensson@pilot.mysql.com +1 -0
  Fixed Bug #27789 "Wrong permissions of sql/share/language directories"

Pushed into 5.1.23-beta

Pushed into 5.0.52

Noted in 5.0.52, 5.1.23 changelogs.

comp_err created files with permissions such that they might not be
accessible during make install operations.