Opened 15 years ago

Closed 15 years ago

Last modified 15 years ago

#21389 closed defect (fixed)

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

Reported by: m@… Owned by: macports-tickets@…
Priority: Normal Milestone: MacPorts 1.8.2
Component: base Version: 1.8.0
Keywords: snowleopard Cc: duanhuaiyu@…, martin@…, jmroot (Joshua Root), 858wildcat@…, mdippery@…
Port:

Description

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.

Change History (17)

comment:1 Changed 15 years ago by tobypeterson

Looks fine here - maybe umask issues?

comment:2 Changed 15 years ago by jmroot (Joshua Root)

Owner: changed from macports-tickets@… to blair@…
Port: db46 added

comment:3 in reply to:  1 ; Changed 15 years ago by 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).

comment:4 Changed 15 years ago by 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.

comment:5 in reply to:  4 Changed 15 years ago by 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?

comment:6 Changed 15 years ago by tobypeterson

Resolution: worksforme
Status: newclosed

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. :-)

comment:7 in reply to:  3 Changed 15 years ago by raimue (Rainer Müller)

Component: portsbase
Keywords: snowleopard added
Milestone: MacPorts Future
Port: db46 removed
Resolution: worksforme
Status: closedreopened
Summary: Wrong permissions in lib/db46, e.g. libdb-4.6.dylibCustomized umask setting produces wrong permissions on installed files on Snow Leopard

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).

comment:8 in reply to:  6 Changed 15 years ago by 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.

comment:9 Changed 15 years ago by blb@…

Cc: duanhuaiyu@… added

Cc reporter of dup #21831.

comment:10 Changed 15 years ago by jmroot (Joshua Root)

Owner: changed from blair@… to macports-tickets@…
Status: reopenednew

comment:11 Changed 15 years ago by martin@…

Cc: martin@… added

Cc Me!

comment:12 Changed 15 years ago by jmroot (Joshua Root)

Cc: jmr@… added
Resolution: fixed
Status: newclosed

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.

comment:13 Changed 15 years ago by jmroot (Joshua Root)

Milestone: MacPorts FutureMacPorts 1.8.2

Merged to the 1.8 branch in r59588.

comment:14 Changed 15 years ago by 858wildcat@…

Cc: 858wildcat@… added

Cc Me!

comment:15 Changed 15 years ago by mdippery@…

Cc: mdippery@… added

Cc Me!

comment:16 Changed 15 years ago by 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).

comment:17 in reply to:  16 Changed 15 years ago by 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.

Note: See TracTickets for help on using tickets.