Re: [PATCH] libc: add issetugid()
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, bas...@opensource.dyc.edu wrote:
From: Anthony G. Basile bluen...@gentoo.org
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=ec106fd17c3aca3287005d21e92f742aa9d4
---
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
+/* 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.
+*/
+extern int issetugid(void);
+#endif
#if (defined __USE_MISC || defined __USE_XOPEN_EXTENDED) !defined F_LOCK
/* NOTE: These declarations also appear in fcntl.h; be sure to keep both
diff --git a/libc/misc/file/issetugid.c b/libc/misc/file/issetugid.c
new file mode 100644
index 000..29a4167
--- /dev/null
+++ b/libc/misc/file/issetugid.c
@@ -0,0 +1,12 @@
+/* Copyright (C) 2013 Gentoo Foundation
+ * Licensed under LGPL v2.1 or later, see the file COPYING.LIB in this tarball.
+ */
+
+#include unistd.h
+
+extern int _pe_secure;
+
+int issetugid(void)
+{
+ return _pe_secure;
+}
diff --git a/libc/misc/internals/__uClibc_main.c
b/libc/misc/internals/__uClibc_main.c
index a37751f..b062e62 100644
--- a/libc/misc/internals/__uClibc_main.c
+++ b/libc/misc/internals/__uClibc_main.c
@@ -40,6 +40,13 @@
#include locale.h
#endif
+/* Are we in a secure process environment or are we dealing
+ * with setuid stuff? If we are dynamically linked, then we
+ * already have _dl_secure, otherwise we need to re-examine
+ * auxvt[].
+ */
+int _pe_secure = 1;
+
#ifndef SHARED
void *__libc_stack_end = NULL;
@@ -387,6 +394,11 @@ void __uClibc_main(int (*main)(int, char **, char **), int
argc,
#else
if (_dl_secure)
#endif
+ _pe_secure = 1 ;
+else
+ _pe_secure = 0 ;
+
+if (_pe_secure)
{
__check_one_fd (STDIN_FILENO, O_RDONLY | O_NOFOLLOW);
__check_one_fd (STDOUT_FILENO, O_RDWR | O_NOFOLLOW);
--
Anthony G. Basile, Ph. D.
Chair of Information Technology
D'Youville College
Buffalo, NY 14201
(716) 829-8197
___
uClibc mailing list
uClibc@uclibc.org
http://lists.busybox.net/mailman/listinfo/uclibc
Re: [OpenWrt-Devel] uClibc-ng
On 7/22/2014 11:30 PM, Steve Bennett wrote: I would like to add my support to Thomas' position. Regardless of what happens with glibc and/or musl, an active community supporting regular releases of uClibc is a good thing. Time has spoken that we can't expect this to happen unless something changes. I agree. It is better to have a responsive maintainer releasing periodic stable versions than to have what is essentially no maintainer and sustained long-term fragmentation of what uClibc really is. If the uClibc maintainer wakes up in the future and begins releasing again, the new project's changes can always be merged back to the parent, as they did with eglibc and glibc. For now we need to focus on making a stable release, something which is grossly overdue and harms all projects currently using uClibc. I also agree that musl is an interesting project with a bright future (and a bright present for that matter), but it does not cover all of what uClibc covers and the number of projects that already require uClibc is too large to simply drop uClibc and move to musl. -Jody Bruchon ___ uClibc mailing list uClibc@uclibc.org http://lists.busybox.net/mailman/listinfo/uclibc
Re: [OpenWrt-Devel] uClibc-ng
Il 23 luglio 2014 13:42:38 Jody Bruchon j...@jodybruchon.com ha scritto: On 7/22/2014 11:30 PM, Steve Bennett wrote: I would like to add my support to Thomas' position. Regardless of what happens with glibc and/or musl, an active community supporting regular releases of uClibc is a good thing. Time has spoken that we can't expect this to happen unless something changes. I agree. It is better to have a responsive maintainer releasing periodic stable versions than to have what is essentially no maintainer and sustained long-term fragmentation of what uClibc really is. If the uClibc maintainer wakes up in the future and begins releasing again, the new project's changes can always be merged back to the parent, as they did with eglibc and glibc. For now we need to focus on making a stable release, something which is grossly overdue and harms all projects currently using uClibc. I also agree that musl is an interesting project with a bright future (and a bright present for that matter), but it does not cover all of what uClibc covers and the number of projects that already require uClibc is too large to simply drop uClibc and move to musl. -Jody Bruchon Gents, Are we considering anyway that Bernard has recently restarted with patches review and commit without no contribution from the other co-maintainers (myself the first) ? Likely Bernard is already preparing a release ! I understand that some comments from Bernard could help to clarify and re-assure the community that uclibc is an alive project still supported. I'm guilty as well as I'm not contributing so actively since one year when my focus @ STMicro has hugely moved from C lib to kernel, but my bandwidth is too low nowadays. I do really hope this project will continue to be used and receive adequate support from the community also providing some acked-by to patches. I do not frankly like that anytime the community raise correctly I'd say concerns against the slowness of releases, it the occasion to push for other C libs; this is not the way to support uClibc project, so please discuss about the wonderful X lib on its own list, not here. Kind regards, Carmelo ___ uClibc mailing list uClibc@uclibc.org http://lists.busybox.net/mailman/listinfo/uclibc Inviato con AquaMail per Android http://www.aqua-mail.com ___ uClibc mailing list uClibc@uclibc.org http://lists.busybox.net/mailman/listinfo/uclibc
