sudo: fails to switch to other user than root

[petrrr]

I have macport's version of sudo installed on my 10.8 system. When I use it to run as root it works fine, when I try to run as a different user (macports), it would fail. I use the default configuration as provided by the port and see no obvious configuration issue.

petr% which sudo
/opt/local/bin/sudo

petr% sudo whoami
Password:
root

petr% sudo -u macports whoami
sudo: unable to change to runas uid (503, 503): Operation not permitted
sudo: unable to execute /usr/bin/whoami: Operation not permitted

petr% sudo -u petr whoami
sudo: unable to change to runas uid (502, 502): Operation not permitted
sudo: unable to execute /usr/bin/whoami: Operation not permitted

petr% whoami
petr

petr% /usr/bin/sudo -u macports whoami
macports

[ryandesign (Ryan Carsten Schmidt)]

The Cc field takes email addresses only.

I have updated sudo to 1.8.8 in r111814. Did that help by any chance?

[petrrr]

Replying to ryandesign@…:

The Cc field takes email addresses only.

Sorry for this, I probably was not careful while copy-pasting.

I have updated sudo to 1.8.8 in r111814. Did that help by any chance?

Unfortunately not. The port now installs ${prefix}/etc/sudoers.dist instead directly sudoers. So I copied it but it still has the same behaviour. I also tried to with the systems version, which works with /usr/bin/sudo. But still the same behaviour.

[raimue (Rainer Müller)]

I did some testing and the older version 1.7.7 did still work using the Portfile version​ before r103948. I guess upstream sudo 1.8 changed anything that causes this to stop working now:

Here is an excerpt from an analysis on sudo @1.8.8_1 using sudo dtruss -f /opt/local/bin/sudo -u macports id showing the failing setuid syscall:

57598/0x12e774:  fork()		 = 0 0
57598/0x12e774:  thread_selfid(0x7FFF75C73180, 0x0, 0x1)		 = 1238900 0
57598/0x12e774:  getpid(0x320000003303, 0x330000003300, 0x7FFF75C62888)		 = 57598 0
57598/0x12e774:  close(0x3)		 = 0 0
57598/0x12e774:  close(0x4)		 = 0 0
57598/0x12e774:  close(0x5)		 = 0 0
57598/0x12e774:  fcntl(0x6, 0x2, 0x1)		 = 0 0
57598/0x12e774:  setgroups(0x3, 0x7FFBF0C21E80, 0x0)		 = 0 0
57598/0x12e774:  setgid(0x1F5, 0x0, 0x0)		 = 0 0
57598/0x12e774:  umask(0x3F, 0x0, 0x0)		 = 63 0
57598/0x12e774:  seteuid(0x1F6, 0x0, 0x0)		 = 0 0
57598/0x12e774:  setuid(0x1F6, 0x0, 0x0)		 = -1 Err#1
57598/0x12e774:  open("/opt/local/share/locale/en_US.UTF-8/LC_MESSAGES/sudo.mo\0", 0x0, 0x10D2AB3D0)		 = -1 Err#2
57598/0x12e774:  open("/opt/local/share/locale/en_US.utf8/LC_MESSAGES/sudo.mo\0", 0x0, 0x10D2AB3D0)		 = -1 Err#2
57598/0x12e774:  open("/opt/local/share/locale/en_US/LC_MESSAGES/sudo.mo\0", 0x0, 0x10D2AB3D0)		 = -1 Err#2
57598/0x12e774:  open("/opt/local/share/locale/en.UTF-8/LC_MESSAGES/sudo.mo\0", 0x0, 0x10D2AB3D0)		 = -1 Err#2
57598/0x12e774:  open("/opt/local/share/locale/en.utf8/LC_MESSAGES/sudo.mo\0", 0x0, 0x10D2AB3D0)		 = -1 Err#2
57598/0x12e774:  open("/opt/local/share/locale/en/LC_MESSAGES/sudo.mo\0", 0x0, 0x10D2AB3D0)		 = -1 Err#2
57598/0x12e774:  write_nocancel(0x2, "sudo: unable to change to runas uid (502, 502): Operation not permitted\n\0", 0x48)		 = 72 0
...

In sudo @1.7.7_0, only setuid(502) is called at this point without any seteuid(502) before. The full log files from my system are attached.

[cooljeanius (Eric Gallager)]

Cc Me!

[evandrix (Lee Wei Yeong)]

Cc Me!

[raimue (Rainer Müller)]

Assigning to maintainer.

[youvegotmoxie@…]

Can recreate, looking into it now.

[youvegotmoxie@…]

Fixed: #48816

[ryandesign (Ryan Carsten Schmidt)]

Could you elaborate on the fix you proposed in #48816? Was this problem reported to the developers of sudo? If so, what is the bug report URL? Did they agree that this is the correct solution?

[raimue (Rainer Müller)]

Your patch attached to #48816​ removes setuid(), which means the real uid of the target will not be set, only the effective uid will be changed. This is not the desired behavior. The seteuid() should be removed, as in ​this upstream change.

Upstream report: ​http://bugzilla.sudo.ws/show_bug.cgi?id=713

Which leaves a question, why are we using --disable-setreuid? Apparently, this bug was only exposed due to this configuration.

[youvegotmoxie@…]

Replying to ryandesign@…:

Could you elaborate on the fix you proposed in #48816? Was this problem reported to the developers of sudo? If so, what is the bug report URL? Did they agree that this is the correct solution?

That is the bug report I opened on the sudo bug tracker as posted by raimue@….

Upstream report: ​​http://bugzilla.sudo.ws/show_bug.cgi?id=713

I am not sure why the Portfile is using --disable-setreuid, without the patched sudo.c and not using --disable-setreuid the aforementioned bug is not present.

[petrrr]

Cc Me!

[raimue (Rainer Müller)]

I propose to remove --disable-setreuid. According to a quick check with svn blame it has always been there. If it was not implemented in some older version of OS X, a workaround can be applied in the appropriate platform block.

[youvegotmoxie@…]

That works for me, although, I have only tested it on Yosemite.

[youvegotmoxie@…]

Remove --disable-setreuid

[neverpanic (Clemens Lang)]

Committed in r143281.