Bug 436447
Summary: | mock fails to switch user, and only runs as root | ||
---|---|---|---|
Product: | [Retired] Fedora Hosted Projects | Reporter: | Joe Cooper <joe> |
Component: | mock | Assignee: | Clark Williams <williams> |
Status: | CLOSED NEXTRELEASE | QA Contact: | |
Severity: | medium | Docs Contact: | |
Priority: | low | ||
Version: | unspecified | CC: | dcantrell, joe.christy, michael_e_brown |
Target Milestone: | --- | ||
Target Release: | --- | ||
Hardware: | All | ||
OS: | Linux | ||
Whiteboard: | |||
Fixed In Version: | Doc Type: | Bug Fix | |
Doc Text: | Story Points: | --- | |
Clone Of: | Environment: | ||
Last Closed: | 2008-03-08 03:19:17 UTC | Type: | --- |
Regression: | --- | Mount Type: | --- |
Documentation: | --- | CRM: | |
Verified Versions: | Category: | --- | |
oVirt Team: | --- | RHEL 7.3 requirements from Atomic Host: | |
Cloudforms Team: | --- | Target Upstream Version: | |
Embargoed: |
Description
Joe Cooper
2008-03-07 09:31:18 UTC
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. |