On Sat, Jul 26, 2014 at 08:12:53AM -0400, Anthony G. Basile wrote: > On 07/24/14 16:41, Bernhard Reutner-Fischer wrote: > >On Wed, Jul 23, 2014 at 07:28:26AM -0400, Anthony G. Basile wrote: > >>I should add that this updated patch addresses Rich's points: 1) I've tested > >>this for both dynamic and static linking and I tested that libressl builds > >>and works correctly. 2) I added a link to the musl commit for the reasoning > >>behind this approach. > >> > >>On 07/22/14 13:27, [email protected] wrote: > >>>From: "Anthony G. Basile" <[email protected]> > >>> > >>>issetugid() returns 1 if the process environment or memory address space > >>>is considered tainted, and returns 0 otherwise. This happens, for example, > >>>when a process's privileges are elevated by the setuid or setgid flags on > >>>an executable belonging to root. This function first appeard in OpenBSD > >>>2.0 > >>>and is needed for the LibreSSL. > >>> > >>>This patch follows the same logic as the equivalent musl commit. For more > >>>information see the commit message at > >>> > >>>http://git.musl-libc.org/cgit/musl/commit/?id=ddddec106fd17c3aca3287005d21e92f742aa9d4 > >>>--- > >>> include/unistd.h | 8 ++++++++ > >>> libc/misc/file/issetugid.c | 12 ++++++++++++ > >>> libc/misc/internals/__uClibc_main.c | 12 ++++++++++++ > >>> 3 files changed, 32 insertions(+) > >>> create mode 100644 libc/misc/file/issetugid.c > >>> > >>>diff --git a/include/unistd.h b/include/unistd.h > >>>index 540062a..6c2c8c2 100644 > >>>--- a/include/unistd.h > >>>+++ b/include/unistd.h > >>>@@ -1168,6 +1168,14 @@ extern long int syscall (long int __sysno, ...) > >>>__THROW; > >>> > >>> #endif /* Use misc. */ > >>> > >>>+#ifdef __USE_MISC > > > >is MISC (or MISC alone) an appropriate guard? > > I had a hard time (and still have a hard time) deciding this even > after carefully reading include/features.h. The function started in > openbsd and migrated to free and netbsd, but its not in 4.3BSD. > _USE_MISC is looser but does include SYS V. I'm thinking now to > just remove the guard. I did speak to Rich about what musl's doing > but it doesn't seem appropriate here. > > If there are no strong opinions, I'll just remove the guard and > resubmit in a few days. > > Your other comments below are good.
I don't think removing the guard would be correct at all; that would expose it even in profiles where the namespace is supposed to conform to POSIX/XSI. If __USE_MISC is inappropriate, the solution would be to move it to a more-inclusive featureset, not a less-inclusive one. Rich _______________________________________________ uClibc mailing list [email protected] http://lists.busybox.net/mailman/listinfo/uclibc
