On Mon, 26 Jun 2023 at 20:04:11 -0400, nick black wrote:
> Simon McVittie left as an exercise for the reader:
> > started as root and dropped privileges to some other uid, that permanently
> > restricts its ability to read information out of its own /proc, which is
> > not always desirable. If the daemon starts up unprivileged, then it can
>
> i assume by "its own /proc" you mean /proc/getpid()?
Yes, the same directory that the /proc/self magic symlink points to.
> furthermore, this is only true when procfs is mounted with a
> nonzero hidepid, right?
No. Mounting /proc with hidepid does make a subset of the /proc/[0-9]*
directories appear to be nonexistent (which breaks surprisingly many
things), but I'm talking about the permissions and ownership of the
pseudo-files inside those directories, not about the presence/absence
of the directories themselves.
If you look at the /proc/$pid of `dbus-daemon --system` (which is a
convenient example of a daemon present on most Debian systems that
currently starts as uid 0 and then drops privileges), you'll see that
for example /proc/$pid/fd/ has 0500 root:root ownership and permissions,
/proc/$pid/auxv is 0400 root:root, and so on. Some (mostly older)
pseudo-files such as /proc/*/stat are world-readable by default, and some
such as /proc/*/net are owned by its post-privilege-dropping identity
messagebus:messagebus, but many remain restricted to root access even
after the process has dropped privileges.
Compare that with `dbus-daemon --session`, which starts as its final uid
(your ordinary user account) and does not drop privileges; everything in
its /proc/$pid is owned by that uid.
> how this is different from any other resource one might need
> consider acquiring prior to dropping privileges. if i want to
> open a privileged port, i'd better do that before i change my
> user (or otherwise yield CAP_NET_BIND_SERVICE).
Not all of the information in /proc/$pid is something that you can
usefully load ahead of time: a lot of it is a dynamic representation
of the state of the process *now*. In particular, some programs rely on
the ability to access /proc/$pid/fd/* to reopen or otherwise manipulate
the program's current set of file descriptors, which needs to act on
the current file descriptor set, and not the file descriptors as they
existed at program start time.
As a concrete example, one of the things on my lengthy to-do list is
reviewing a proposed feature for dbus-daemon to allow use of process file
descriptors (pidfds) in future kernels, which will eventually let D-Bus
clients like polkitd use pidfds to refer to processes by using a pidfd as
a "process handle" without the time-of-check/time-of-use race conditions
inherent in using numeric process IDs.
It's looking as though that will require access to /proc/$pid/fd/*
in order to "pin" process file descriptors, and that in turn will
require dbus.service to start `dbus-daemon --system` with its final uid
(messagebus) instead of starting as root and then dropping privileges
to messagebus.
smcv
