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.
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?
/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!
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.
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.
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.
"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.
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
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.
"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.