Opened 9 years ago

Closed 4 years ago

Last modified 4 years ago

#50918 closed defect (fixed)

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

Reported by: mojca (Mojca Miklavec) Owned by: neverpanic (Clemens Lang)
Priority: Normal Milestone: MacPorts 2.6.3
Component: base Version: 2.3.4
Keywords: Cc: ryandesign (Ryan Carsten Schmidt)
Port: buildbot-slave-0.8

Description (last modified by 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:

Change History (15)

comment:1 Changed 9 years ago by mojca (Mojca Miklavec)

Description: modified (diff)

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

comment:3 Changed 9 years ago by 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,

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

comment:5 Changed 9 years ago by ryandesign (Ryan Carsten Schmidt)

Cc: ryandesign@… added

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

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

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

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

comment:9 Changed 8 years ago by ryandesign (Ryan Carsten Schmidt)

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

Worked around the problem in buildbot-slave in r150504.

comment:10 Changed 8 years ago by mojca (Mojca Miklavec)

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

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

comment:12 Changed 5 years ago by mojca (Mojca Miklavec)

Port: buildbot-slave-0.8 added; buildbot-slave removed

comment:13 Changed 4 years ago by neverpanic (Clemens Lang)

Status: newaccepted

comment:14 Changed 4 years ago by neverpanic (Clemens Lang)

Resolution: fixed
Status: acceptedclosed

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

comment:15 Changed 4 years ago by neverpanic (Clemens Lang)

Milestone: MacPorts 2.6.3
Note: See TracTickets for help on using tickets.