Follow @Openwall on Twitter for new release announcements and other news
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Date: Wed, 16 Jul 2014 21:33:11 -0500
From: Brent Cook <>
To: Rich Felker <>
Subject: Re: [PATCH] implement issetugid(2) (v4)

On Jul 16, 2014, at 8:08 PM, Rich Felker <> wrote:

> On Tue, Jul 15, 2014 at 03:29:01PM -0500, Brent Cook wrote:
>> On Jul 15, 2014, at 3:16 PM, Rich Felker <> wrote:
>>> On Tue, Jul 15, 2014 at 04:30:07PM +0000, Brent Cook wrote:
>>>>> From OpenBSD 2.0 and later, NetBSD, FreeBSD, OS X and Solaris
>>>> [...]
>>> In this form, I think the code is now simple, clean, and correct. The
>>> only thing I'd still like to check on is whether it's been proposed to
>>> glibc and whether we can possibly get them on board with providing a
>>> compatible function. While I think it's unlikely that there could be
>>> any incompatibilities in such a simple function, I'd like to foster
>>> the kind of cooperation on adding new interfaces like this that
>>> unifies APIs rather than having each system go their own way and just
>>> add things without consideration for furthering the goals of
>>> compatibility and standardization.
>> No, I have not contacted the glibc folks yet. I thought it would
>> make sense to work out the details and discussion with just one C
>> library first, and the ease of building/testing musl made it a
>> no-brainer.
>> Yes, without a doubt, this would be great to have in glibc too.
> So far the response I got from the glibc side has been fairly
> negative. Do you have any reaction to the claim that the BSD and
> Solaris versions of this function are different/incompatible? As far
> as I can tell they're the same.

In testing, SmartOS and Solaris 11 appears to work the same way as the OpenBSD version.

FreeBSD 9 and 10 work correctly as well.

Solaris 10 has been reported to have a bug, but I wouldn’t call it an incompatible implementation (since they fixed it later anyway):

> I agree with them that the name is ugly and something of a misnomer,
> but adding yet another function just to "fix" the name on platforms
> where this already exists seems silly.

I would agree with you as well about the name on both counts, but it is what it is. There are plenty of bad compatibility-wrapper implementations out there that this would help get rid of at the same time.

> My leaning so far is to include issetugid even if the glibc folks
> don't want to, since there seems to be no remotely portable way to
> achieve the same thing without it. The suggestion of using getauxval
> is much more low-level and tied to particular implementations (ELF or
> ELF-like ones with aux vector or which emulate it), and I don't think
> it's a reliable approach for applications linked to musl (since they
> might be running on a 2.4 kernel). So even if software has to have a
> fallback for glibc systems, I'd prefer that it use a libc-provided
> issetugid() on musl so that we can provide a reliable answer rather
> than asking the caller to make assumptions about the system.

OK, thanks for considering it.

> Rich

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.