-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
All,
The inside-out version of mock (or upside-down, depending on your perspective) seems to be working. For those that don't know what I'm talking about, we've been looking at changing the way mock deals with uid/gid manipulation to improve security a bit. The old way was for /usr/bin/mock to be a link to mock.py and whenever mock wanted to do something that required root privilege, it called a setuid root program called /usr/sbin/mock-helper. This program knew how to do a select few commands (chroot, mount, etc.) and did some argument validation. Unfortunately mock-helper has some security issues and extending it would require us to write more C code. While most of us aren't afraid of writing C code, writing *secure* C code is not simple and in this case it's probably not worth the effort.
Someone (Michael?) suggested that we turn everything around and write a simple setuid root/setgid mock launcher program that would then start mock.py and allow it to manipulate privilege from python code. I wrote the first cut at a launcher and then added code to mock.py to elevate and drop privileges around commands that needed it. I now have a set of code that will build simple SRPMS (elinks, rsync, tar, etc.) and would like to get some other eyeballs on this code. The "new" organization is we have a /usr/bin/mock that is a setuid C program which only knows how to exec /usr/bin/mock.py.
While none of the changes are massive, they are spread across a few files (Makefile, mock.py, mock.spec, etc/default.cfg, src/Makefile, src/mock.c) so I'm wondering if I should just blast out the files to the list, or if I should cut a branch in CVS and let people look at it from there? Or, should I just check it in and if the consensus is that it sucks, we can change or revert?
Thoughts?
Clark