buildbot-slave: file mkdir in post-extract creates a dir owned by root

[mojca (Mojca Miklavec)]

The buildbot-slave port is broken:

Error: reinplace: error copying "/path/to/work/.tmp/org.macports.buildslave.template.plist.sed.n5fhoMQm" to "/path/to/work/buildbot-slave-0.8.12/macports/org.macports.buildslave.template.plist": permission denied
Error: org.macports.patch for port buildbot-slave returned: reinplace copy failed

I'm not sure if the port should use a different syntax or if this is a bug in base (or if I did something wrong).

These are the files/folders that I end up in ${worksrcpath}.

...
drwxr-xr-x   3 macports  admin    102 21 Apr  2015 docs
drwxr-xr-x   3 root      admin    102 18 Mar 11:45 macports
-rw-r--r--   1 macports  admin     37 21 Apr  2015 setup.cfg
-rwxr-xr-x   1 macports  admin   4830 21 Apr  2015 setup.py

This seems to be fixed in trunk, but not in the released version. See:

• ​https://build.macports.org/builders/buildports-snowleopard-x86_64/builds/40851
• ​https://build.macports.org/builders/buildports-elcapitan-x86_64/builds/438

[mojca (Mojca Miklavec)]

A viable workaround is to copy the file elsewhere (and thus avoid creating a directory owned by root). But I would be grateful for the "second opinion".

[ctreleaven (Craig Treleaven)]

Several of us have had our hands in this port recently but I started the ball rolling and contributed the bit you seem to be having trouble with. Which confuses me since it worked for me in test, passed the buildbots and worked again when I set up a (MythTV) build-slave 2 weeks ago.

Could you please clean, try again and post a full build log? Thanks,

[mojca (Mojca Miklavec)]

You have full logs from the buildbots available on the two links above. I can add my log, but it won't contribute any new information. If you are running MacPorts from trunk, you are most likely not affected.

The compilations on the buildbots didn't succeed. The build step is shown in green (probably an error in the buildbot setup), but the build actually failed.

[ryandesign (Ryan Carsten Schmidt)]

Confirmed on my local machine with 2.3.4. Not sure why things get created as root in the post-extract block...

[mojca (Mojca Miklavec)]

My suggestion would be to simply work around the problem for now and not create a folder (but simply put the file to the top folder), so that the port will no longer be broken. And perhaps make a new test to guard against that strange behaviour. If the problem is fixed in trunk, we can put an enormous amount of energy trying to find the relevant commit, but at the end there will hardly be any benefit, in particular if you plan to do a release some time soon and if there will be no patch release (2.3.5).

[neverpanic (Clemens Lang)]

This might be related to privilege separation. My guess is that privileges are not dropped again after they were first picked up. I recently added a add_users statement to the port, which is handled in the extract phase and requires privileges. If those aren't dropped again properly after the adduser (in port1.0/portutil.tcl) that would lead to this.

Additionally, I've noticed that setting $phase.asroot causes privileges to be escalated, but I haven't found a corresponding drop. This should be fixed.

[ryandesign (Ryan Carsten Schmidt)]

Replying to mojca@…:

This seems to be fixed in trunk, but not in the released version.

I'm seeing the problem with trunk as well.

[ryandesign (Ryan Carsten Schmidt)]

It's definitely the add_users call that triggers this behavior.

Worked around the problem in buildbot-slave in r150504.

[mojca (Mojca Miklavec)]

Should we then "rename" this ticket to track permission problems or should we open a new one?

[ryandesign (Ryan Carsten Schmidt)]

The component of this ticket is already "base" so I figured this ticket would be used to track the base issue.

[neverpanic (Clemens Lang)]

​https://github.com/macports/macports-base/pull/192

[neverpanic (Clemens Lang)]

In ac1a9b0991ffb34769847d188a9c71fbce24d65c/macports-base (master):

port1.0: Ensure adduser drops privs in all cases

adduser and addgroup (invoked by the add_users statement in
handle_add_users) elevates its privileges, but does not always drop them
again. Specifically, this could happen if a user or group already
existed, in which case adduser did elevate to root, but not drop back to
the macportsuser again.

This can cause files to be created with incorrect permissions, which can
then cause permissions problems in subsequent phases.

Closes: #50918

[neverpanic (Clemens Lang)]

Backport to 2.6 is [fcb9cd207563a64bdc841ac8f97b044fcbeb0e46/macports-base].