Customized umask setting produces wrong permissions on installed files on Snow Leopard

[m@…]

I did a fresh install after upgrading to Snow Leopard. The installed ports include Subversion.

Unfortunately, I can run svn only as user admin. With my restricted account, I get the following error message:

$ /opt/local/bin/svn                                                                 (15.09. 10:43)
dyld: Library not loaded: /opt/local/lib/db46/libdb-4.6.dylib
  Referenced from: /opt/local/bin/svn
  Reason: no suitable image found.  Did find:
        /opt/local/lib/db46/libdb-4.6.dylib: open() failed with errno=13
[1]    715 trace trap  /opt/local/bin/svn

This seems to be a bug related to the persmissions in /opt/local/lib/db46/:

$ ls -la /opt/local/lib/db46/
total 25296
drwxr-xr-x   2 root  admin      714 Sep 11 14:57 .
drwxr-xr-x  10 root  admin     8024 Sep 14 12:07 ..
-r--r--r--   2 root  admin   247975 Sep 11 14:57 db.jar
-rw-r--r--   2 root  admin  1657904 Sep 11 14:57 libdb-4.6.a
-rwxr-x---   2 root  admin  1146208 Sep 11 14:57 libdb-4.6.dylib
-rw-r-----   2 root  admin      830 Sep 11 14:57 libdb-4.6.la
lrwxr-x---   1 root  admin       15 Sep 11 14:57 libdb-4.dylib -> libdb-4.6.dylib
-rw-r--r--   2 root  admin  1657904 Sep 11 14:57 libdb.a
lrwxr-x---   1 root  admin       15 Sep 11 14:57 libdb.dylib -> libdb-4.6.dylib
-rw-r--r--   2 root  admin  1867600 Sep 11 14:57 libdb_cxx-4.6.a
-rwxr-x---   2 root  admin  1278928 Sep 11 14:57 libdb_cxx-4.6.dylib
-rw-r-----   2 root  admin      858 Sep 11 14:57 libdb_cxx-4.6.la
lrwxr-x---   1 root  admin       19 Sep 11 14:57 libdb_cxx-4.dylib -> libdb_cxx-4.6.dylib
-rw-r--r--   2 root  admin  1867600 Sep 11 14:57 libdb_cxx.a
lrwxr-x---   1 root  admin       19 Sep 11 14:57 libdb_cxx.dylib -> libdb_cxx-4.6.dylib
-rw-r--r--   2 root  admin  1881928 Sep 11 14:57 libdb_java-4.6.a
-rwxr-x---   2 root  admin  1291072 Sep 11 14:57 libdb_java-4.6.jnilib
-rw-r-----   2 root  admin      869 Sep 11 14:57 libdb_java-4.6.la
lrwxr-x---   1 root  admin       21 Sep 11 14:57 libdb_java-4.6_g.jnilib -> libdb_java-4.6.jnilib
lrwxr-x---   1 root  admin       21 Sep 11 14:57 libdb_java-4.jnilib -> libdb_java-4.6.jnilib
lrwxr-x---   1 root  admin       21 Sep 11 14:57 libdb_java.jnilib -> libdb_java-4.6.jnilib

File /opt/local/lib/db46/libdb-4.6.dylib is not world readable.

[tobypeterson]

Looks fine here - maybe umask issues?

[m@…]

Replying to toby@…:

Looks fine here - maybe umask issues?

This could be a relevant circumstance, indeed:

admin:~$ umask
0027

However, it worked before and still works for other ports. So, my umask setting should not be the actual cause (defect).

[blair (Blair Zajac)]

The fact that it works for other ports doesn't mean that we'll take the time to support it for this port.

Can you try setting your umask to 0022, removing the db46 port and reinstalling it and see if that fixes the issue.

[m@…]

Replying to blair@…:

The fact that it works for other ports doesn't mean that we'll take the time to support it for this port.

Can you try setting your umask to 0022, removing the db46 port and reinstalling it and see if that fixes the issue.

This helped:

admin:~$ umask
0022
# Uninstalling and installing subversion-javahlbindings subversion serf apr-util db46
admin:~$ ls -la /opt/local/lib/db46/
total 25296
drwxr-xr-x  2 root  admin      714 Sep 15 22:27 .
drwxr-xr-x  9 root  admin     5236 Sep 15 22:28 ..
-r--r--r--  2 root  admin   247975 Sep 15 22:27 db.jar
-rw-r--r--  2 root  admin  1657904 Sep 15 22:27 libdb-4.6.a
-rwxr-xr-x  2 root  admin  1146208 Sep 15 22:27 libdb-4.6.dylib
-rw-r--r--  2 root  admin      830 Sep 15 22:27 libdb-4.6.la
lrwxr-xr-x  1 root  admin       15 Sep 15 22:27 libdb-4.dylib -> libdb-4.6.dylib
-rw-r--r--  2 root  admin  1657904 Sep 15 22:27 libdb.a
lrwxr-xr-x  1 root  admin       15 Sep 15 22:27 libdb.dylib -> libdb-4.6.dylib
-rw-r--r--  2 root  admin  1867600 Sep 15 22:27 libdb_cxx-4.6.a
-rwxr-xr-x  2 root  admin  1278928 Sep 15 22:27 libdb_cxx-4.6.dylib
-rw-r--r--  2 root  admin      858 Sep 15 22:27 libdb_cxx-4.6.la
lrwxr-xr-x  1 root  admin       19 Sep 15 22:27 libdb_cxx-4.dylib -> libdb_cxx-4.6.dylib
-rw-r--r--  2 root  admin  1867600 Sep 15 22:27 libdb_cxx.a
lrwxr-xr-x  1 root  admin       19 Sep 15 22:27 libdb_cxx.dylib -> libdb_cxx-4.6.dylib
-rw-r--r--  2 root  admin  1881928 Sep 15 22:27 libdb_java-4.6.a
-rwxr-xr-x  2 root  admin  1291072 Sep 15 22:27 libdb_java-4.6.jnilib
-rw-r--r--  2 root  admin      869 Sep 15 22:27 libdb_java-4.6.la
lrwxr-xr-x  1 root  admin       21 Sep 15 22:27 libdb_java-4.6_g.jnilib -> libdb_java-4.6.jnilib
lrwxr-xr-x  1 root  admin       21 Sep 15 22:27 libdb_java-4.jnilib -> libdb_java-4.6.jnilib
lrwxr-xr-x  1 root  admin       21 Sep 15 22:27 libdb_java.jnilib -> libdb_java-4.6.jnilib

However, this is somehow inconvenient, isn't it?

[tobypeterson]

umask 027 means you don't want to allow access to other users. So we're doing the right thing.

If you want things to be accessible for other users, don't use umask 027. :-)

[raimue (Rainer Müller)]

Replying to m@…:

However, it worked before and still works for other ports. So, my umask setting should not be the actual cause (defect).

I have encountered the same problem and apparently sudo handles umask differently on Snow Leopard by inheriting the user's umask. We just need a way to deal with this new behavior. This is not a problem for ports using /usr/bin/install and xinstall as this explicitely changes the permissions, but for everything using e.g. cp or file copy this can be an issue. Also the receipt files and everything else MacPorts creates (distfiles, build directories, work symlink) will have the "wrong" permissions.

My proposal is to add a new --with-umask setting to the configure script in the same style we already have --with-install-user, --with-install-group and --with-directory-mode. It would default to 0022.

Changing the umask setting affects the current process and any new forks, so after loading the macports Tcl extension it would be changed for this process. Could this be a problem for any software?

The alternative would be to explicitely set permissions on every file creation which would be complicated and require rewrite where we use Tcl API (e.g. file copy).

[m@…]

Replying to toby@…:

umask 027 means you don't want to allow access to other users. So we're doing the right thing.

If you want things to be accessible for other users, don't use umask 027. :-)

I am of another opinion. I think you should differentiate between files explicitly created, like documents, and files copied by a package manager. Similar to Debian packages, a system administrator expects that an installed package works for all users, right? This is, at least, a usability problem - an issue that is underestimated too often, in my humble opinion.

[blb@…]

Cc reporter of dup #21831.

[martin@…]

Cc Me!

[jmroot (Joshua Root)]

Turns out we already have a destroot_umask setting that just wasn't listed in macports.conf. So anything affected by this is leaving the permissions like the build phase created them. I added a reasonable starting umask setting in r59585.

[jmroot (Joshua Root)]

Merged to the 1.8 branch in r59588.

[858wildcat@…]

Cc Me!

[mdippery@…]

Cc Me!

[mdippery@…]

This problem also affects files in, e.g., /opt/local/var/macports/receipts and /opt/local/var/macports/software. My umask setting is 0022, and this means that files in these directories get installed with owner/group "root/admin", but is readable only by root. This means that commands like port installed and port outdated must be run in conjunction with sudo, which is kind of annoying (this wasn't the case on 10.4 and 10.5).

[mdippery@…]

Replying to mdippery@…:

This problem also affects files in, e.g., /opt/local/var/macports/receipts and /opt/local/var/macports/software. My umask setting is 0022, and this means that files in these directories get installed with owner/group "root/admin", but is readable only by root. This means that commands like port installed and port outdated must be run in conjunction with sudo, which is kind of annoying (this wasn't the case on 10.4 and 10.5).

That is, my umask is 0077. Whoops.