[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-Id: <B7F2A3F8-E43D-47AA-B607-54FA383A138C@gmail.com>
Date: Wed, 16 Jul 2014 21:33:11 -0500
From: Brent Cook <busterb@...il.com>
To: Rich Felker <dalias@...c.org>
Cc: musl@...ts.openwall.com,
beck@...nbsd.org
Subject: Re: [PATCH] implement issetugid(2) (v4)
On Jul 16, 2014, at 8:08 PM, Rich Felker <dalias@...c.org> wrote:
> On Tue, Jul 15, 2014 at 03:29:01PM -0500, Brent Cook wrote:
>> On Jul 15, 2014, at 3:16 PM, Rich Felker <dalias@...c.org> 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
>>>> http://www.openbsd.org/cgi-bin/man.cgi?query=issetugid&sektion=2
>>>> [...]
>>>
>>> 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):
http://mcarpenter.org/blog/2013/01/15/solaris-issetugid(2)-bug
> 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.
