Date: Thu, 15 Oct 2020 11:43:23 -0400 From: Rich Felker <dalias@...c.org> To: musl@...ts.openwall.com Subject: Re: Why is setrlimit() considered to have per-thread effect? On Thu, Oct 15, 2020 at 08:01:00AM +0300, Alexey Izbyshev wrote: > Hello, > > Commit 544ee752cd claims that setrlimit() is per-thread on Linux, > similarly to setxid() calls, so it should be called via > __synccall(). But this appears to be wrong: the kernel code operates > on tsk->signal, which is a per-thread-group structure. Glibc > doesn't call setrlimit() for each thread either. Am I missing > something? POSIX specifies that it sets the limits for the process. If the kernel doesn't do that, we have to implement in userspace. > Tangentially, setgroups() is not called via __synccall(), though it > does have per-thread effect. Is this intentional? POSIX doesn't define setgroups, so it's up to the implementation. Conceptually since POSIX has supplemental groups they probably *should* be forced process-global, so maybe we should change this. For an example that's more clear-cut, setfs[ug]id is explicitly not process-global because it's not a security boundary and the whole purpose is to be able to do local id changes then revert them for the sake of performing access as a different user/group. Rich
Powered by blists - more mailing lists
Confused about mailing lists and their use? Read about mailing lists on Wikipedia and check out these guidelines on proper formatting of your messages.