* [PATCH] implement issetugid(2) (v4) @ 2014-07-15 16:30 Brent Cook 2014-07-15 20:16 ` Rich Felker 0 siblings, 1 reply; 10+ messages in thread From: Brent Cook @ 2014-07-15 16:30 UTC (permalink / raw) To: musl; +Cc: beck From OpenBSD 2.0 and later, NetBSD, FreeBSD, OS X and Solaris http://www.openbsd.org/cgi-bin/man.cgi?query=issetugid&sektion=2 While getauxval(AT_SECURE) might have been able to provide comparable functionality on the libc versions that support it, several Linux libc versions implement it in a way such that the results cannot be trusted, since there is no way to tell if it has failed. Worse, the result of '0' returned on failures effectively causes the security mechanism to fail 'open'. There is also no simultaneously reliable and portable way for a library to identify if the C library has a usable version of getauxval, since the symbol is unversioned. Compile-time checks for usability are also unfeasible, since static libraries built with a 'good' version can be linked to a 'bad' version of getauxval. The fix is to implement the BSD issetugid(2) interface so that a portable library can use its presence to determine if the underlying C library has a reliable way of determining if it is running in a secure mode. --- include/unistd.h | 1 + src/unistd/issetugid.c | 7 +++++++ 2 files changed, 8 insertions(+) create mode 100644 src/unistd/issetugid.c diff --git a/include/unistd.h b/include/unistd.h index bb19cd8..ac6055a 100644 --- a/include/unistd.h +++ b/include/unistd.h @@ -178,6 +178,7 @@ char *getusershell(void); int acct(const char *); long syscall(long, ...); int execvpe(const char *, char *const [], char *const []); +int issetugid(void); #endif #ifdef _GNU_SOURCE diff --git a/src/unistd/issetugid.c b/src/unistd/issetugid.c new file mode 100644 index 0000000..6ffd930 --- /dev/null +++ b/src/unistd/issetugid.c @@ -0,0 +1,7 @@ +#include <unistd.h> +#include "libc.h" + +int issetugid(void) +{ + return libc.secure; +} -- 1.9.1 ^ permalink raw reply [flat|nested] 10+ messages in thread
* Re: [PATCH] implement issetugid(2) (v4) 2014-07-15 16:30 [PATCH] implement issetugid(2) (v4) Brent Cook @ 2014-07-15 20:16 ` Rich Felker 2014-07-15 20:29 ` Brent Cook 0 siblings, 1 reply; 10+ messages in thread From: Rich Felker @ 2014-07-15 20:16 UTC (permalink / raw) To: Brent Cook; +Cc: musl, beck 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. Has anyone contacted the glibc folks yet? If not, would you like me to do so? Rich ^ permalink raw reply [flat|nested] 10+ messages in thread
* Re: [PATCH] implement issetugid(2) (v4) 2014-07-15 20:16 ` Rich Felker @ 2014-07-15 20:29 ` Brent Cook 2014-07-17 1:08 ` Rich Felker 0 siblings, 1 reply; 10+ messages in thread From: Brent Cook @ 2014-07-15 20:29 UTC (permalink / raw) To: Rich Felker; +Cc: musl, beck On Jul 15, 2014, at 3:16 PM, Rich Felker <dalias@libc.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. > Has anyone contacted the glibc folks yet? If not, would you like me to > do so? Yes, if you don’t mind. It looks like it could be implemented in a very simple way there as well. > Rich ^ permalink raw reply [flat|nested] 10+ messages in thread
* Re: [PATCH] implement issetugid(2) (v4) 2014-07-15 20:29 ` Brent Cook @ 2014-07-17 1:08 ` Rich Felker 2014-07-17 2:33 ` Brent Cook 2014-07-18 1:50 ` Isaac Dunham 0 siblings, 2 replies; 10+ messages in thread From: Rich Felker @ 2014-07-17 1:08 UTC (permalink / raw) To: Brent Cook; +Cc: musl, beck On Tue, Jul 15, 2014 at 03:29:01PM -0500, Brent Cook wrote: > On Jul 15, 2014, at 3:16 PM, Rich Felker <dalias@libc.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 ^ permalink raw reply [flat|nested] 10+ messages in thread
* Re: [PATCH] implement issetugid(2) (v4) 2014-07-17 1:08 ` Rich Felker @ 2014-07-17 2:33 ` Brent Cook 2014-07-19 20:07 ` Rich Felker 2014-07-18 1:50 ` Isaac Dunham 1 sibling, 1 reply; 10+ messages in thread From: Brent Cook @ 2014-07-17 2:33 UTC (permalink / raw) To: Rich Felker; +Cc: musl, beck On Jul 16, 2014, at 8:08 PM, Rich Felker <dalias@libc.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@libc.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 ^ permalink raw reply [flat|nested] 10+ messages in thread
* Re: [PATCH] implement issetugid(2) (v4) 2014-07-17 2:33 ` Brent Cook @ 2014-07-19 20:07 ` Rich Felker 2014-07-20 1:45 ` Rich Felker 0 siblings, 1 reply; 10+ messages in thread From: Rich Felker @ 2014-07-19 20:07 UTC (permalink / raw) To: musl; +Cc: beck, Brent Cook 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 ^ permalink raw reply [flat|nested] 10+ messages in thread
* Re: [PATCH] implement issetugid(2) (v4) 2014-07-19 20:07 ` Rich Felker @ 2014-07-20 1:45 ` Rich Felker 2014-07-20 2:02 ` Brent Cook 0 siblings, 1 reply; 10+ messages in thread From: Rich Felker @ 2014-07-20 1:45 UTC (permalink / raw) To: musl; +Cc: beck, Brent Cook On Sat, Jul 19, 2014 at 04:07:25PM -0400, Rich Felker wrote: > 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. Committed! Rich ^ permalink raw reply [flat|nested] 10+ messages in thread
* Re: [PATCH] implement issetugid(2) (v4) 2014-07-20 1:45 ` Rich Felker @ 2014-07-20 2:02 ` Brent Cook 0 siblings, 0 replies; 10+ messages in thread From: Brent Cook @ 2014-07-20 2:02 UTC (permalink / raw) To: musl; +Cc: Bob Beck [-- Attachment #1: Type: text/plain, Size: 1095 bytes --] Nice, thanks! On Jul 19, 2014 8:45 PM, "Rich Felker" <dalias@libc.org> wrote: > On Sat, Jul 19, 2014 at 04:07:25PM -0400, Rich Felker wrote: > > 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. > > Committed! > > Rich > [-- Attachment #2: Type: text/html, Size: 1528 bytes --] ^ permalink raw reply [flat|nested] 10+ messages in thread
* Re: [PATCH] implement issetugid(2) (v4) 2014-07-17 1:08 ` Rich Felker 2014-07-17 2:33 ` Brent Cook @ 2014-07-18 1:50 ` Isaac Dunham 2014-07-18 1:58 ` Rich Felker 1 sibling, 1 reply; 10+ messages in thread From: Isaac Dunham @ 2014-07-18 1:50 UTC (permalink / raw) To: Rich Felker; +Cc: Brent Cook, musl, beck A thought recently crossed my mind regarding getauxval(AT_SECURE): what does this do under Linux emulation on other platforms? Most of the BSDs have Linux emulation, as well as Solaris; there was also LINA for Windows and OS X. But I haven't found statements about what happens to getauxval(). Thanks, Isaac Dunham ^ permalink raw reply [flat|nested] 10+ messages in thread
* Re: [PATCH] implement issetugid(2) (v4) 2014-07-18 1:50 ` Isaac Dunham @ 2014-07-18 1:58 ` Rich Felker 0 siblings, 0 replies; 10+ messages in thread From: Rich Felker @ 2014-07-18 1:58 UTC (permalink / raw) To: Isaac Dunham; +Cc: Brent Cook, musl, beck On Sat, Jul 19, 2014 at 04:11:17AM -0700, Isaac Dunham wrote: > A thought recently crossed my mind regarding getauxval(AT_SECURE): > what does this do under Linux emulation on other platforms? > Most of the BSDs have Linux emulation, as well as Solaris; > there was also LINA for Windows and OS X. > But I haven't found statements about what happens to getauxval(). Both glibc's and musl's getauxval will just return results from whatever aux vector the kernel gave the program when it started. If AT_SECURE is missing from the aux vector the kernel provides, this will lead to ENOENT on musl and newer glibc, and to a false negative on old glibc. For this reason I think musl should intercept the request for AT_SECURE and simply return libc.secure rather than the value in the aux vector. In principle applications should be checking for ENOENT, but since glibc "guarantees" it cannot happen by not supporting pre-AT_SECURE kernels (and not making any statement about other kernels with Linux emulation), applications are likely to be skipping the ENOENT check. Rich ^ permalink raw reply [flat|nested] 10+ messages in thread
end of thread, other threads:[~2014-07-20 2:02 UTC | newest] Thread overview: 10+ messages (download: mbox.gz / follow: Atom feed) -- links below jump to the message on this page -- 2014-07-15 16:30 [PATCH] implement issetugid(2) (v4) Brent Cook 2014-07-15 20:16 ` Rich Felker 2014-07-15 20:29 ` Brent Cook 2014-07-17 1:08 ` Rich Felker 2014-07-17 2:33 ` Brent Cook 2014-07-19 20:07 ` Rich Felker 2014-07-20 1:45 ` Rich Felker 2014-07-20 2:02 ` Brent Cook 2014-07-18 1:50 ` Isaac Dunham 2014-07-18 1:58 ` Rich Felker
Code repositories for project(s) associated with this public inbox https://git.vuxu.org/mirror/musl/ This is a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox; as well as URLs for NNTP newsgroup(s).