This is the mail archive of the libc-alpha@sourceware.org mailing list for the glibc project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

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


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]