[Bug libc/31784] RFE: ability to control ambient caps in posix_spawn/pidfd_spawn

mzglcbz at 0pointer dot net sourceware-bugzilla@sourceware.org
Wed May 22 21:12:05 GMT 2024


https://sourceware.org/bugzilla/show_bug.cgi?id=31784

--- Comment #4 from Lennart Poettering <mzglcbz at 0pointer dot net> ---
Hmm, yeah, being able to schedule prctl calls would probably suffice for our
primary usecase, i.e. PR_CAP_AMBIENT_RAISE.

But I wonder how feature proof that is. The thing is that various prctl() calls
have to be executed in some well-defined order. I.e. let's say you use this to
seal the "secure bits" of a process (PR_SET_SECUREBITS), or set
PR_SET_NO_NEW_PRIVS or drop caps from the bounding set: this things need to be
scheduled in a precise order, so that you don't end up dropping the permissions
necessary to execute the next prctl operation. Now, it's probably fine to
outsource this ordering to the caller. However, this becomes a complete mess
once in future pidfd_spawn/posix_spawn is extended to cover more stuff, for
example setresuid() or so. Suddenly, the order in which prctls are executed
also must be matched up with the time where setresuid() is invoked: if you use
prctl to drop privs before changing uid, the uid will fail. 

Hence, yes, would certainly cover our specific usecase, and I guess would be
simple to add to glibc, but I sense this is going to become a mess later on if
you do this, since ordering these operations against what glibc itself wants to
do is going to be problematic.

-- 
You are receiving this mail because:
You are on the CC list for the bug.


More information about the Glibc-bugs mailing list