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.