Hi, 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 some group*. 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. Bye,
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 though.
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 requirement. 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 a chroot.
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. :-/