Date: Wed, 16 Jul 2014 21:08:30 -0400 From: Rich Felker <dalias@...c.org> To: Brent Cook <busterb@...il.com> Cc: musl@...ts.openwall.com, beck@...nbsd.org Subject: Re: [PATCH] implement issetugid(2) (v4) 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. 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. 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. 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.