From: Alexey Izbyshev <izbyshev@ispras.ru>
To: musl@lists.openwall.com
Subject: [musl] Calling setxid() in a vfork()-child
Date: Mon, 12 Oct 2020 12:27:44 +0300 [thread overview]
Message-ID: <93cbaeffbc860a145843e0380058c50e@ispras.ru> (raw)
Hello,
I'm investigating possibility of using vfork() instead of fork() in a
Linux-only application. Before calling execve(), the app might need to
call some functions to setup the child, including setxid() (let's assume
that security concerns of [1] are not applicable). I'm aware that POSIX
doesn't allow that for vfork()-children, but I'm also aware that it
might be OK on Linux if the set of functions is sufficiently
constrained, and that vfork() is used to efficiently implement
posix_spawn() in C libraries. However, setuid()/setgid() seem
particularly tricky because of the need to call the actual syscall in
all threads, so if a C library is unaware that setxid() is called in a
vfork()-child, it might attempt to interact with threads of the parent
process, potentially causing trouble. I've checked musl and found a
recent commit[2] that fixes this exact issue. I've also checked
glibc[3], but haven't found any handling of this case (and vfork()
doesn't appear to do anything special in this regard either[4]).
Do I understand correctly that, from an application developer
perspective, it's currently better to avoid setxid/setrlimit libc
functions in a vfork()-child, and that using syscall() or avoiding
vfork() entirely is preferred in this case?
Thanks,
Alexey
[1] https://sourceware.org/bugzilla/show_bug.cgi?id=14749
[2] https://git.musl-libc.org/cgit/musl/commit/?id=a5aff1972
[3]
https://sourceware.org/git?p=glibc.git;a=blob;f=nptl/allocatestack.c;h=4b45f8c884b;hb=HEAD#l1082
[4]
https://sourceware.org/git?p=glibc.git;a=blob;f=sysdeps/unix/sysv/linux/x86_64/vfork.S;h=776d2fc61;hb=HEAD#l44
next reply other threads:[~2020-10-12 9:28 UTC|newest]
Thread overview: 10+ messages / expand[flat|nested] mbox.gz Atom feed top
2020-10-12 9:27 Alexey Izbyshev [this message]
2020-10-12 14:55 ` Rich Felker
2020-10-12 20:30 ` Alexey Izbyshev
2020-10-13 2:47 ` Markus Wichmann
2020-10-13 9:52 ` Laurent Bercot
2020-10-13 15:48 ` Alexey Izbyshev
2020-10-13 15:24 ` Alexey Izbyshev
2020-10-13 16:07 ` Rich Felker
2020-10-13 16:52 ` Alexey Izbyshev
2020-10-13 17:05 ` Rich Felker
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=93cbaeffbc860a145843e0380058c50e@ispras.ru \
--to=izbyshev@ispras.ru \
--cc=musl@lists.openwall.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
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).