[systemd-devel] PrivateDevices with more than basic set of devices?

Lennart Poettering lennart at poettering.net
Mon Jan 26 08:13:33 PST 2015

On Sat, 24.01.15 10:09, Topi Miettinen (toiwoton at gmail.com) wrote:

> Hello,
> It would be useful to be able to use PrivateDevices with additional
> devices to the basic set (null, zero, urandom etc). For example, smartd
> only needs access to /dev/sd*. It would be a bit complex to do this
> without help of systemd, you would have to set up the private /dev
> filesystem by hand before starting the daemon.

First of all, smartd usually only acesses /dev/sd*, but it actually
has drivers that use quite a few other device nodes too (for example
to support that weird SCSI SMART stuff). Thus, limiting access to only
/dev/sd* might work in many specific cases, but certainly not in the
general case.

However, the bigger problem is that setting /dev up like that would
not be a one-time thing. As new devices appear or old devices
disappear the device nodes in the service-specific /dev would have to
be created/updated/removed. And that's substantial complexity.

PrivateDevices= is supposed to be a one-stop solution for services
that that need zero device access, and I am not convinced we should
turn it into more than that. It's supposed to be simple, easy to
understand. Right now, I can tell people easily: "hey, if your service
never needs access to physical devices, turn on PrivateDevices=!", and
it is really that easy, there's nothing more to know. However, if we
turn this into something more than that, then the whole thing becomes
a ton more complex, not only in code, but also in explaining it to

Also, the level of security that PrivateDevices= provides is not
substantially more than configuring the "devices" cgroup
controller. The latter only controls access, the former also hides the
device nodes, but that's about it. However, the latter you configure
much more flexibily, and you can do one thing specifically: you can
actually configure access to device nodes of whole classes of
things. For example "DeviceAllow=block-sd" can enforce access
limitation on what you are asking for. And it doesn't need any
complexity to handle when devices come and go, because the rule is
independent of actual device nodes in the file system.

> How about this: When PrivateDevices is enabled (perhaps with a new
> extended mode like PrivateDevices=Auto?), any DeviceAllow directives
> would automatically append the device in question to the list of devices
> to be copied to the private /dev. The list of devices could be stated
> with a new directive instead (CopyDevices=/dev/sda /dev/sdb).
> Or perhaps tmpfiles.d should be extended instead, that would allow more
> actions than just device setup? For example, unit files could point to a
> tmpfiles.d directory or file that will be processed inside the unit
> container before the unit is executed?

Both of these proposals cannot deal with devices coming and going, and
that's kind of a major deal breaker, since we try not to wait for
devices during boot-up more than necessary, and hence not even for
always plugged in devices this could ever work without races...



Lennart Poettering, Red Hat

More information about the systemd-devel mailing list