Re: [PATCH] Declare set*id with warn_unused_result

[Rich Felker <dalias at aerifal dot cx>]

On Tue, Jul 24, 2012 at 08:18:38AM -0700, Paul Eggert wrote:
> On 07/24/2012 07:48 AM, Rich Felker wrote:
> > Even if it can't fail on your setup, it means
> > your program is dangerously non-portable
> 
> Do other operating systems also have this kernel bug?
> 
> Even if so, __wur is not about warning developers that their
> programs might not be portable to other operating systems.
> That would be too ambitious a goal.  Nor is it about
> warning developers that there might be kernel bugs -- that'd
> be another goal that might expand without limit.  __wur is
> about warning developers that their programs are buggy, with
> a reasonably large degree of certainty.

printf("hello %s\n", (char *)0); is a bug and gcc/glibc warn about it
(glibc plays a part in the warning by using the format string
attribute tag on the declaration of printf). On glibc, it happens to
have predictable behavior, but it's still worth warning about because
it's wrong. Likewise, assuming a security-critical function succeeded
when its failure could yield privilege elevation vulns is a bug, even
if you're working on a platform where it presently never fails (which
is not the case, anyway, as discussed in the rest of the thread).

> Surely it's a more productive use of everybody's time to fix
> the kernels, than to write, test, and debug workarounds in all
> the applications that use these kernels.

I think you'll find the kernel developers unwilling to fix this bug,
since it requires reversing a bad design decision and putting the data
back in the task structure where it originally was and where it
belongs.

> > This kind of code is a fundamental bug.
> 
> Not in the gnulib context; the code in question is
> only for single-threaded applications.
> 
> As it happens, the example code is never used in GNU/Linux,
> so if the bug is present only in Linux kernels there won't be
> any reason to change Gnulib.  Still, the point is that
> using seteuid to bop back and forth between real and effective
> UID is not uncommon and there should be no need to warn
> about such usage.

For what it's worth, I think there's a lot less danger of the
effective uid change failing. It was never subject to RLIMIT_NPROCS.
Still there may be ENOMEM reasons it could fail...

Rich