On Fri, Jan 05, 2007 at 10:52:04AM -0600, Clark Williams wrote: > Axel Thimm wrote: > > In a nutshell: you now carry much more unlimited root power throughout > > all of mock's invocation cycle in comparison to a confined set of > > priviledges that the helper was giving. > > Good point. I still think it's easier to audit python code than C code, > but you're talking 500 lines of C versus 1000 lines of python. So, I may > just reconsider this change. > > One of the reasons I liked moving to a setuid/setgid launcher was that > we could move the process into the mock group and fix a bunch of chroot > sharing problems with appropriate group permissions. Oh, and we actually > kick off the python process in a separate namespace, which means we > won't dirty up the mount table if for some reason we exit unexpectedly. > > If we just made the launcher setgid:mock and kept mock-helper for > rootiness things, would that still trigger your security alarms? Hmmm, > now that I think about it, we probably have to be root to create a new > namespace, so the launcher might have to stay setuid:root and drop > privileges before exec'ing python. > > Thoughts?
How about a very radical approach: Removing the neccessity to have root priviledges at the first place anywhere. The benefits are clear security-wise, and you get the added bonus that you can have people install mock under their $HOME w/o being root on these system (imagine students working on campus/lab PCs). One could even create a Fedora SDK that runs on non-rpm Linux platforms - mock infiltrates everything ;) The question is whether that is technically possible - for what I use at ATrpms, an ancient bunch of shell scripts being the equivalent of mock, I use fakechroot/fakeroot to maintain chroots as a simple user. I think that will work with eliminating the need for the chroot part in the mock helper as well. If we check the remaining parts in mock requiring root priviledges (perhaps just for mounting?) perhaps we can eliminate these, too, and end up with a pure non-root working mock. I submitted fakeroot/fakechroot shortly before 2006 phased out, once they are through one can start playing with them (I think fakechroot is there, still waiting for fakeroot+dependency reviews to complete). BTW the Debian/Ubuntu build systems make extensive use of fakeroot/fakechroot for exactly the same scenarios. -- Axel.Thimm at ATrpms.net
pgp1jU7Y6OodN.pgp
Description: PGP signature
-- Fedora-buildsys-list mailing list Fedora-buildsys-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-buildsys-list
