From mboxrd@z Thu Jan 1 00:00:00 1970 X-Msuck: nntp://news.gmane.org/gmane.linux.lib.musl.general/5527 Path: news.gmane.org!not-for-mail From: Rich Felker Newsgroups: gmane.linux.lib.musl.general Subject: Re: [PATCH] implement issetugid(2) (v4) Date: Sat, 19 Jul 2014 16:07:25 -0400 Message-ID: <20140719200725.GC17402@brightrain.aerifal.cx> References: <1405441807-5327-1-git-send-email-bcook@openbsd.org> <20140715201637.GI17402@brightrain.aerifal.cx> <20140717010830.GO17402@brightrain.aerifal.cx> Reply-To: musl@lists.openwall.com NNTP-Posting-Host: plane.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Trace: ger.gmane.org 1405800468 1202 80.91.229.3 (19 Jul 2014 20:07:48 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Sat, 19 Jul 2014 20:07:48 +0000 (UTC) Cc: beck@openbsd.org, Brent Cook To: musl@lists.openwall.com Original-X-From: musl-return-5532-gllmg-musl=m.gmane.org@lists.openwall.com Sat Jul 19 22:07:41 2014 Return-path: Envelope-to: gllmg-musl@plane.gmane.org Original-Received: from mother.openwall.net ([195.42.179.200]) by plane.gmane.org with smtp (Exim 4.69) (envelope-from ) id 1X8auy-0001HS-JR for gllmg-musl@plane.gmane.org; Sat, 19 Jul 2014 22:07:40 +0200 Original-Received: (qmail 22431 invoked by uid 550); 19 Jul 2014 20:07:39 -0000 Mailing-List: contact musl-help@lists.openwall.com; run by ezmlm Precedence: bulk List-Post: List-Help: List-Unsubscribe: List-Subscribe: Original-Received: (qmail 22423 invoked from network); 19 Jul 2014 20:07:38 -0000 Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.21 (2010-09-15) Original-Sender: Rich Felker Xref: news.gmane.org gmane.linux.lib.musl.general:5527 Archived-At: On Wed, Jul 16, 2014 at 09:33:11PM -0500, Brent Cook wrote: > > 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. Based on the discussion so far, I'm going to commit it. I'm moving the file to a different location though (probably src/misc unless anyone has a better idea) since the aim (not 100% followed right now) is to keep the "standard" directories reserved for either standard functions or nonstandard extensions that clearly belong in the same functional group (like stdio or thread extensions). Having issetugid under unistd seems more like a BSD implementation detail (doing it as a syscall) than a logical grouping. Of course keeping the prototype in unistd.h makes sense just because we shouldn't break apps' expectations for where to get it. The other thing I'd like to do is summarize the discussions of why it makes sense for musl to adopt this as a commit message. The message in your email is nice as an argument from the BSD side, but I'd also like to address why it (and other remarks) have been convincing. Rich