New Ticket     Tickets     Wiki     Browse Source     Timeline     Roadmap     Ticket Reports     Search

Ticket #21389 (closed defect: fixed)

Opened 5 years ago

Last modified 4 years ago

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@…, jmr@…, 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

comment:1 follow-up: ↓ 3 Changed 5 years ago by toby@…

Looks fine here - maybe umask issues?

comment:2 Changed 5 years ago by jmr@…

  • Owner changed from macports-tickets@… to blair@…
  • Port set to db46

comment:3 in reply to: ↑ 1 ; follow-up: ↓ 7 Changed 5 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 follow-up: ↓ 5 Changed 5 years ago by 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.

comment:5 in reply to: ↑ 4 Changed 5 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 follow-up: ↓ 8 Changed 5 years ago by toby@…

  • Status changed from new to closed
  • Resolution set to worksforme

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 5 years ago by raimue@…

  • Status changed from closed to reopened
  • Component changed from ports to base
  • Summary changed from Wrong permissions in lib/db46, e.g. libdb-4.6.dylib to Customized umask setting produces wrong permissions on installed files on Snow Leopard
  • Milestone set to MacPorts Future
  • Keywords snowleopard added
  • Resolution worksforme deleted
  • Port db46 deleted

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 5 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 5 years ago by blb@…

  • Cc duanhuaiyu@… added

Cc reporter of dup #21831.

comment:10 Changed 5 years ago by jmr@…

  • Status changed from reopened to new
  • Owner changed from blair@… to macports-tickets@…

comment:11 Changed 5 years ago by martin@…

  • Cc martin@… added

Cc Me!

comment:12 Changed 5 years ago by jmr@…

  • Cc jmr@… added
  • Status changed from new to closed
  • Resolution set to fixed

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 5 years ago by jmr@…

  • Milestone changed from MacPorts Future to MacPorts 1.8.2

Merged to the 1.8 branch in r59588.

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

  • Cc 858wildcat@… added

Cc Me!

comment:15 Changed 4 years ago by mdippery@…

  • Cc mdippery@… added

Cc Me!

comment:16 follow-up: ↓ 17 Changed 4 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 4 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.