Re: issetugid?

[Rich Felker <dalias at libc dot org>]

On Wed, Jul 16, 2014 at 09:31:41AM +0200, Florian Weimer wrote:
> On 07/16/2014 06:07 AM, Rich Felker wrote:
> >In the interest of fostering cooperation rather than fragmentation
> >when adding new APIs like this, I'd like to know if the glibc side has
> >any interest in adding this function, or any objections to the way it
> >works on BSDs and what's been proposed for inclusion in musl (see the
> >link above).
> 
> glibc already offers getauxval(AT_SECURE) and
> prctl(PR_GET_DUMPABLE), so I'm not sure if another interface is
> needed.

This is a very good point. The LibreSSL folks are claiming that
getauxval(AT_SECURE) is not safe due to the lack of any way to detect
bug #15846 at runtime (and trying to use a strverscmp against the
glibc version string as a way to know if the bug is present...).
However, I think they're wrong because AT_SECURE is always included in
the aux vector for all kernels glibc supports; ENOENT cannot happen.
And if there were a way to suppress AT_SECURE, it would affect
LD_PRELOAD etc. anyway and thus already be a vulnerability independent
of getauxval's reporting of errors.

I don't think prctl(PR_GET_DUMPABLE) is relevant or useful for this
since it would have to be tested at startup before any application
code runs in order to reflect the AT_SECURE status.

> On Linux, the function name issetugid is misleading because you
> generally want to include transitions caused by Linux Security
> Modules which do not alter UID or GID as well.

I agree that the name was poorly chosen, but I'm not sure that it's
worth inventing yet another name rather than just documenting the
discrepency.

> What's worse, the Solaris and FreeBSD versions of issetugid are
> different, so we'd have to pick one behavior and be incompatible
> with the other.

Could you explain how they differ? I'm reading the Solaris
documentation here:

http://docs.oracle.com/cd/E23823_01/html/816-5167/issetugid-2.html

and it appears to match the semantics that were proposed for addition
to musl.

Based on your comments, I agree that this interface is non-essential,
but I still think it might be nice to have. While on glibc it's
probably equivalent to getauxval(AT_SECURE), musl partially (with
limited functionality) supports 2.4 kernels, and other systems may not
even provide getauxval (whose interface is closer to the low-level
internals rather than the outward semantics the application should
care about) so I think using something like issetugid() is a cleaner
approach for portable application code.

Rich