Follow @Openwall on Twitter for new release announcements and other news
[<prev] [next>] [day] [month] [year] [list]
Date: Wed, 16 Jul 2014 13:53:12 -0400
From: Rich Felker <>
To: Florian Weimer <>
Subject: Re: issetugid?

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

> 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:

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.


Powered by blists - more mailing lists

Confused about mailing lists and their use? Read about mailing lists on Wikipedia and check out these guidelines on proper formatting of your messages.