-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1

Clark Williams wrote:

...

...

// elevate our privileges
if (setreuid (geteuid (), geteuid ()))
    error("setreuid failed: %s", strerror(errno));
debug("running with uid: %d, gid: %d\n", getuid(), getgid());

Is this necessary? It seems to me like this is something that can be done in mock.py for the cases where it is necessary, as mock.py might need to know the user id of the person running mock, and so it can switch back to that user for writing output files.

So, you're thinking we just to seteuid/setegid rather than setting the real uid/gid?

Ok, I pulled out my shiny new 2nd Edition copy of "Advanced Programming in the UNIX Environment" to try jog a brain cell or three about uid/gid manipulation. Now that I reread what you said, it sounds like you want me just to leave it alone and manipulate effective uid/gid only when we need to in mock.py.

Is that a correct statement?

Clark

Michael_E_Brown@Dell.com wrote:

// elevate our privileges if (setreuid (geteuid (), geteuid ())) error("setreuid failed: %s", strerror(errno)); debug("running with uid: %d, gid: %d\n", getuid(), getgid());

Is this necessary? It seems to me like this is something that can be done in mock.py for the cases where it is necessary, as mock.py might need to know the user id of the person running mock, and so it can switch back to that user for writing output files.

Another option is to pass the original user in a environment variable (like sudo does).

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1

Mike McLean wrote:

Clark Williams wrote:

...

Note that the program makes use of Linux namespaces. This *should* make our handling of mount points within the chroot (/proc, /sys, etc.) a bit easier to clean up, since when the process dies the mounts should just go away. I haven't verified this though, so caveat emptor.

Using namespaces does not relieve us of managing our mounts. For example, mock.py still needs to make sure the mounts are gone before attempting to remove a buildroot. It mainly serves as a safety net.

I suppose I should have said "if the process terminates abnormally" as opposed to "when the process dies". I realize that we can't whack a directory that still has a mount on/in it and that namespaces do nothing for us there.

...

#ifdef USE_SELINUX // add LD_PRELOAD for our selinux lib if selinux is in use is set

I don't think the SELINUX preload needs to be done here anymore. mock.py can set it up when running mock-yum if need be.

Yeah, I meant to ask that on my original email. I didn't build the new mock.c with USE_SELINUX enabled, because I wasn't sure if we were going to need it, or if we were going to push forward with a mock SELinux policy, or something completely different. I will admit to not having paid the closest attention to all the SELinux traffic on the lists lately... :).

As I recall, we do an LD_PRELOAD of our .so before going into the chroot, so that selinux is effectively disabled in the chroot. Personally, I think that SELinux is a bit of overkill inside a chroot, but someone running at a high-security facility may feel differently.

I'm ok with letting mock.py manage the addition of LD_PRELOAD to the chroot and moving it out of the launcher. The code is only complete when you can remove no more...

Clark