mit-scheme port fails with permission denied error

[jkh@…]

This does not happen for all ports (I am able to build scheme48 successfully, for example) but, in this example, mit-scheme fails with a rather bizarre error. Debug output is as follows:

jkh@wunga-> sudo port -d -v install mit-scheme
Password:
DEBUG: Changing to port directory: /Users/jkh/Src/macports/dports/lang/mit-scheme
DEBUG: OS darwin/10.4.0 (Mac OS X 10.6) arch i386
DEBUG: org.macports.load registered provides 'load', a pre-existing procedure. Target override will not be provided
DEBUG: org.macports.unload registered provides 'unload', a pre-existing procedure. Target override will not be provided
DEBUG: org.macports.distfiles registered provides 'distfiles', a pre-existing procedure. Target override will not be provided
DEBUG: universal_variant is false, so not adding the default universal variant
DEBUG: changing euid/egid - current euid: 0 - current egid: 0
DEBUG: egid changed to: 4294967294
DEBUG: euid changed to: 4294967294
DEBUG: could not read "/Users/jkh/Src/macports/dports/lang/mit-scheme/Portfile": permission denied
    while executing
"file mtime ${portpath}/Portfile"
    (procedure "open_statefile" line 46)
    invoked from within
"open_statefile"
    (procedure "check_variants" line 29)
    invoked from within
"check_variants activate"
    invoked from within
"$workername eval check_variants $target"
    (procedure "mportexec" line 7)
    invoked from within
"mportexec $workername $target"
Error: Unable to execute port: could not read "/Users/jkh/Src/macports/dports/lang/mit-scheme/Portfile": permission denied
To report a bug, see <http://guide.macports.org/#project.tickets>

[blb@…]

Same thing happened to me, I'm guessing you're on trunk instead of 1.9.1; seems to be because port is now using nobody instead of root in certain phases, and some path up to /Users/jkh/Src/macports/dports/lang/mit-scheme probably doesn't let nobody see things. I just did a mode 711 on one of my directories, and things worked out after.

[jmroot (Joshua Root)]

Right, the default macportsuser setting in macports.conf is now nobody. Make sure your ports tree is fully readable by that user, or change it to root like it used to be if you prefer.

[jkh@…]

I'm afraid you may be on the wrong track:

jkh@wunga-> ls -l /Users/jkh/Src/macports/dports/lang/mit-scheme/Portfile -rw-r--r-- 1 jkh staff 2730 Aug 15 09:22 /Users/jkh/Src/macports/dports/lang/mit-scheme/Portfile

As you can see, this Portfile is readable by all, yet the euid/guid changing scheme is evidently flawed since setting macportsuser to ANY user other than root (I tried several, altering permissions accordingly) does not work. Did you try this with sudo, as in my example? I suspect a bad sudo/macports interaction here. Again, this is also with trunk - please repro with trunk and macportsuser NOT set to root (which works fine - I checked that also).

[jmroot (Joshua Root)]

I am using trunk with macportsuser=nobody, running with sudo, and a ​file:// source; and mit-scheme builds for me. So given that your permissions are OK, I don't know why it would fail for you.

[blb@…]

Replying to jkh@…:

I'm afraid you may be on the wrong track:

jkh@wunga-> ls -l /Users/jkh/Src/macports/dports/lang/mit-scheme/Portfile -rw-r--r-- 1 jkh staff 2730 Aug 15 09:22 /Users/jkh/Src/macports/dports/lang/mit-scheme/Portfile

Yeah, but what about sudo -u nobody ls -l /Users/jkh/Src/macports/dports/lang/mit-scheme/Portfile? Odds are you ran into what I did, a parent up the chain isn't readable by nobody (in my case it was an immediate subdir of my $HOME).

[mkae (Marko Käning)]

Cc Me!

[mkae (Marko Käning)]

egid and euid look rather wild, don't they?

Another example of this problem can be found in the duplicate #30332

[jmroot (Joshua Root)]

Looks like the correct uid/gid for nobody to me. The test suggested by blb in comment:5 is still relevant. If you can't perform the operation in a shell as the user used by MacPorts, then it's not a problem with anything MacPorts is doing.

[mkae (Marko Käning)]

Thanks, jmr, I hadn't spotted that hint.

Yes, I can verify that a similar test does fail in my case.

markos-imac:~ marko$ ls /Users/marko/WC/MacPorts/ports/kde/kmymoney4/Portfile.my
/Users/marko/WC/MacPorts/ports/kde/kmymoney4/Portfile.my
markos-imac:~ marko$ sudo -u nobody ls -l /Users/marko/WC/MacPorts/ports/kde/kmymoney4/Portfile.my
ls: /Users/marko/WC/MacPorts/ports/kde/kmymoney4/Portfile.my: Permission denied

Turns out the folder WC in my HOME was private. I hadn't done this myself, not that I know of. Looks like that some unknown application modified the permissions. Great find, thanks again, jmr!

I think this ticket can be considered closed.