Red Hat Bugzilla – Bug 219911
Fails to run as root
Last modified: 2013-01-09 23:09:40 EST
When invoking mock as root:
# mock -r fedora-devel-x86_64-core --debug init
You need to be a member of the mock group for this to work
I don't think it's reasonnable to refuse to root to run *because he is not in
I would prefer mock to run as root because this sets a sane owner/group for
unpacked files in the chroot (root).
I understand mock might want to refuse running as root at all for security
reasons (FYI, mach permits running as root), but there should be a separate
test/message for this case.
Personally I'd rather it never run as root, raises the barrier to something
silly happening to the root file system. I'll leave it up to Clark to decide
Actually, I've never been a fan of the "must be a member of the mock" group. The
next version of mock that will go into rawhide (mock-0.7+) will remove that
I can move the root check up so that the message makes more sense, but I'm
trying not to do major changes to the 0.6x branch. So for now mock will continue
to have the "no root" and "must be in group mock" behavior.
Hopefully I'll get the new version out to rawhide around the first of the year.
Why don't you set the target milestone to 0.7.0 then?
Also, how will you filter users who are allowed to run the SUID root helper
mock-helper? In particular, it allows chrooting, but it's trivial to get out of
I would set the target milestone if I could figure out how.
The idea in mock-0.7 is to do away with mock-helper altogether and replace it
with a setuid:root launcher named mock. The new launcher just runs
/usr/libexec/mock.py as root (in a new namespace) and mock.py then raises and
lowers privledge levels as needed.
(In reply to comment #4)
> I would set the target milestone if I could figure out how.
Move the mock ticketing to http://hosted.fedoraproject.org/projects/mock ? (:
@Clark: you still need a way to restrict who's going to be allowed to use the
suid root wrapper (which might see security holes), or which privileges.
Feel free to move the report across ticketing systems, but closing it because
another behavior might be implemented in a future redesign branch doesn't
encourage me to file enhancement bugs against mock. :-/