This is the mail archive of the
libc-alpha@sourceware.org
mailing list for the glibc project.
Re: [PATCH] Declare set*id with warn_unused_result
On Tue, Jul 24, 2012 at 07:46:40AM -0700, Paul Eggert wrote:
> On 07/24/2012 06:42 AM, Florian Weimer wrote:
>
> > It could (and probably should) call abort because something has gone
> > horribly wrong.
>
> Library functions that call abort() can cause further problems.
This is true, but library functions have no business calling setuid
etc. in the first place. The uid is process-global, not per-thread, so
a library calling it will _dangerously_ affect the behavior of other
threads. There are basically only 2 places you can use setuid in a
valid secure program: either right after program startup (after
opening some resources that required elevated privileges like low
ports or device nodes or raw sockets), or right after forking a child
process to handle a user's connection (for ftpd, sshd, etc.).
> > even current kernels code can return ENOMEM, it is just harder to hit.
>
> ?!? Worse and worse. Where is this documented?
> It sounds like another kernel bug....
It is. They perform memory allocation to replace the privilege
structure used by the task rather than just storing the stuff in the
task structure. I suspect this was a misguided attempt at being more
"extensible", i.e. fools can add whatever junk they want to the
privilege objects without mucking around with the task structure.
> The issue that a program often cannot do anything reasonable if the
> system call fails. Here's an example abstracted from Gnulib: it's a
> library function that does something like this:
>
> int
> dosomething (void)
> {
> uid_t euid = geteuid ();
> int result;
> seteuid (getuid ());
> result = something ();
> seteuid (euid);
> return result;
> }
This kind of code is a fundamental bug. See above.
Rich