Opened 14 years ago

Closed 13 years ago

#26094 closed defect (invalid)

mit-scheme port fails with permission denied error

Reported by: jkh@… Owned by: macports-tickets@…
Priority: Normal Milestone:
Component: base Version: 1.9.99
Keywords: Cc: mkae (Marko Käning)
Port:

Description (last modified by blb@…)

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>

Change History (10)

comment:1 Changed 14 years ago by blb@…

Description: modified (diff)

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.

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

Component: portsbase
Resolution: worksforme
Status: newclosed
Version: 1.9.11.9.99

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.

comment:3 Changed 14 years ago by jkh@…

Resolution: worksforme
Status: closedreopened

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

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

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

comment:6 Changed 13 years ago by mkae (Marko Käning)

Cc: mk@… added

Cc Me!

comment:7 Changed 13 years ago by 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

comment:8 Changed 13 years ago by 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.

comment:9 Changed 13 years ago by 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.

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

Resolution: invalid
Status: reopenedclosed
Note: See TracTickets for help on using tickets.