Bug 436447 - mock fails to switch user, and only runs as root
mock fails to switch user, and only runs as root
Status: CLOSED NEXTRELEASE
Product: Fedora Hosted Projects
Classification: Retired
Component: mock (Show other bugs)
unspecified
All Linux
low Severity medium
: ---
: ---
Assigned To: Clark Williams
:
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2008-03-07 04:31 EST by Joe Cooper
Modified: 2013-01-09 23:35 EST (History)
3 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2008-03-07 22:19:17 EST
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:


Attachments (Terms of Use)

  None (edit)
Description Joe Cooper 2008-03-07 04:31:18 EST
Description of problem:

When run as a user in the mock group, this error results immediately:

$ mock -r fedora-7-i386 rebuild php5-5.2.4-3vm.src.rpm ERROR: [Errno 1]
Operation not permitted
Traceback (most recent call last):
  File "/usr/sbin/mock", line 630, in <module>
    main(retParams)
  File "/usr/sbin/mock", line 412, in main
    uidManager._becomeUser(unprivUid, unprivGid)
  File "<peak.util.decorators.rewrap wrapping mock.uid._becomeUser at
0x008F5500>", line 3, in _becomeUser
    def _becomeUser(self, uid, gid): return __decorated(self, uid, gid)
  File "/usr/lib/python2.5/site-packages/mock/trace_decorator.py", line 70, in trace
    result = func(*args, **kw)
  File "/usr/lib/python2.5/site-packages/mock/uid.py", line 65, in _becomeUser
    self._elevatePrivs()
  File "<peak.util.decorators.rewrap wrapping mock.uid._elevatePrivs at
0x008F2F50>", line 3, in _elevatePrivs
    def _elevatePrivs(self): return __decorated(self)
  File "/usr/lib/python2.5/site-packages/mock/trace_decorator.py", line 70, in trace
    result = func(*args, **kw)
  File "/usr/lib/python2.5/site-packages/mock/uid.py", line 60, in _elevatePrivs
    setresuid(0, 0, 0)
  File "/usr/lib/python2.5/site-packages/mock/uid.py", line 91, in setresuid
    raise OSError(_errno.value, os.strerror(_errno.value))
OSError: [Errno 1] Operation not permitted

When run with sudo, just for grins, this problem doesn't occur, though there
still seems to be some issues.

Version-Release number of selected component (if applicable):

0.9.7, using the default fedora-7-i386 and fedora-8-i386 cfg files that ship in
the F7 mock package, as well as trying several of my older known-to-work in
older versions cfg files for various platforms.

This issue is somewhat recent...earlier mock versions did not exhibit this
problem on this system.

SELinux is disabled on the system, which is a fully updated Fedora 7 running on
x86_64.

How reproducible:

Always.

Steps to Reproduce:
1. Run mock as a non-root user (but that is in the mock group)
  
Actual results:

Python traceback provided above.

Expected results:

Successful build, or at least a sensible error message that helps user to
resolve configuration problems, if any.

Additional info:

I've tried explicitly setting config_opts['chrootuid'] and
config_opts['chrootgid'] in the configuration file, using the defaults.cfg file
values as an example, to no effect.  Doing this actually did cause a very
similar error to go away in mock 0.8.x, so I thought it was worth a shot.

I've also tried setting it explicitly to my user UID and the mock GID, on the
theory that maybe my Python os lib might be broken somehow, which also fails
identically...so the ID lookups aren't the culprit here.
Comment 1 Clark Williams 2008-03-07 13:23:25 EST
What does the PATH look like when you run it as a non-root user? is /usr/sbin
ahead of /usr/bin in the path?
Comment 2 Joe Cooper 2008-03-07 16:23:06 EST
/usr/kerberos/bin:/usr/local/sbin:/usr/sbin:/sbin:/usr/java/jre1.5.0_09/bin:/usr/local/bin:/usr/bin:/bin:/home/joe/bin


So, yes, /usr/sbin is ahead of /usr/bin.  Swapping the order makes this
traceback go away.  I reckon we can call this resolved...though, it might be
useful to mention this in the docs, or provide a sane error message if it is
known that having /usr/sbin in the PATH can break things so completely.  The
traceback is pretty much incomprehensible (to me, anyway).

Thanks for the quick reply!
Comment 3 Joe Christy 2008-03-07 18:34:24 EST
Call me a dinosaur, but hasn't it long been common practice that when
{/usr,}/sbin appears in a *nix PATH, it comes before {/usr,}/bin? The reason
being that, if you have the need and the privilege to run programs in
{/usr,}/sbin, then you don't want to be running a wrapper script in {/usr,}/bin
instead. I know that that's the way I've been doing it for 25 years.

I'd not call this resolved, esp. since it used to work the other way.
Comment 4 Michael E Brown 2008-03-07 18:44:26 EST
Ok, since you asked, you are a dinosaur.

Programs are in /usr/sbin for a reason: they need elevated privs, or are
intended to be run by admins. If you are running a program from /usr/sbin/ as an
*unprivileged* user, then you should not be surprised when they dont work as
expected.

So: If you have /usr/sbin/ in your path before /usr/bin, then you had better be
running with elevated privs.

This is operating *exactly* as expected, intended, designed, etc.
Comment 5 Michael E Brown 2008-03-07 18:49:05 EST
From the FHS: http://pathname.com/fhs/pub/fhs-2.3.html
======================
/usr/sbin : Non-essential standard system binaries
Purpose

This directory contains any non-essential binaries used exclusively by the
system administrator. System administration programs that are required for
system repair, system recovery, mounting /usr, or other essential functions must
be placed in /sbin instead. [29]
======================

Ie. If you are a normal user, you shouldnt expect that programs installed here
will work for you.
Comment 6 Joe Cooper 2008-03-07 19:05:44 EST
"Programs are in /usr/sbin for a reason: they need elevated privs, or are
intended to be run by admins. If you are running a program from /usr/sbin/ as an
*unprivileged* user, then you should not be surprised when they dont work as
expected."

But this fails to take into account sudo, which is the way I run anything that
requires elevated privileges, and as our dinosaur friend pointed out,
historically, you do actually want the sbin variant in those cases.

Regardless, I don't really care whether it'll work with sbin early in the path
or not--I just think the error should be sane, or the behavior should be
documented, and currently it is not.
Comment 7 Michael E Brown 2008-03-07 22:17:18 EST
sorry, I'm not following you. If you use sudo, then you are absolutely not
*unprivileged* anymore. And, in this circumstance, mock works just fine:

  $ sudo /usr/sbin/mock --rebuild ...  # WORKS
Comment 8 Michael E Brown 2008-03-07 22:19:17 EST
I've added a check for this to the next version of mock to give a more usable
error message for this circumstance. Will show up in the next release.

$ ./mock.py -r fedora-8-x86_64 --clean

ERROR: [Errno 1] Operation not permitted

ERROR: The most common cause for this error is trying to run /usr/sbin/mock as
an unprivileged user.
ERROR: Check your path to make sure that /usr/bin/ is listed before /usr/sbin,
or manually run /usr/bin/mock to see if that fixes this problem.
Comment 9 Joe Cooper 2008-03-08 04:24:38 EST
"sorry, I'm not following you. If you use sudo, then you are absolutely not
*unprivileged* anymore. And, in this circumstance, mock works just fine:"

Yes, and that was actually stated in my original ticket.  My point was that
because my user account is sudo-capable, I have /sbin and /usr/sbin in my path,
and I'm sure I'm not alone in that...not that I would ever want to run mock
under sudo.

But I'm content.  This error message is fine.

Note You need to log in before you can comment on or make changes to this bug.