Follow @Openwall on Twitter for new release announcements and other news
[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
Date: Mon, 07 Nov 2022 18:09:01 +0100
From: Florian Weimer <>
To: Rich Felker <>
Subject: Re: Per-thread file system attributes

* Rich Felker:

>> > The "filesystem uid/gid" extension Linux has (setfsuid/setfsgid) is
>> > already per-thread by convention due glibc choosing (and musl & uclibc
>> > doing likewise) not to make it process-global with a broadcast. It's a
>> > lot more suitable than overloading the POSIX real/effective/saved
>> > uid/gid for this purpose, as the latter are intended as security
>> > boundaries and the "fs" ones are just intended for implementing file
>> > servers.
>> setfsuid/setfsgid have been deprecated since the switch to different
>> setresuid semantics in the kernel.  And you could never use them to
>> handle supplementary groups, I think.
> Do you have a reference for that change? I was unaware of it. This
> seems rather unfortunate.

It's in the manual page for kill:

| For a process to have permission to send a signal, it must either
| be privileged (under Linux: have the CAP_KILL capability in the
| user namespace of the target process), or the real or effective
| user ID of the sending process must equal the real or saved set-
| user-ID of the target process.  In the case of SIGCONT, it

  [NB: not the effective user ID of the target]

| suffices when the sending and receiving processes belong to the
| same session.  (Historically, the rules were different; see
| Linux notes
| Across different kernel versions, Linux has  enforced  different  rules
| for the permissions required for an unprivileged process to send a sig‐
| nal to another process.  In kernels 1.0 to 1.2.2,  a  signal  could  be
| sent  if  the effective user ID of the sender matched effective user ID
| of the target, or the real user ID of the sender matched the real  user
| ID  of  the  target.  From kernel 1.2.3 until 1.3.77, a signal could be
| sent if the effective user ID of the sender matched either the real  or
| effective  user  ID of the target.  The current rules, which conform to
| POSIX.1, were adopted in kernel 1.3.78.


In practice, I think FSUID confers pretty much the same privileges as
EUID, so I don't think it's a regression in security hardening
capabilities or something like that.

And of course, there's also the supplementary groups issue, which was
never covered under the FSUID/FSGID approach.


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.