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

[Topi Miettinen]

On 01/26/15 16:13, Lennart Poettering wrote:
> 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
> people.

I think the code would not get much complex. The device list would be
gathered and passed to mount_dev() in namespace.c. And documentation can
be easily expanded.

> 
> 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.

Good point.

> 
>> 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...

Maybe udev should be able to handle several /dev directories in the
system, each with a different configuration...

But independently of the PrivateDevices thing, would you think
tmpfiles.d could be extended to be usable for unit specific cases
instead of just one global setup? I think there could be more uses, for
example, creating directories and links inside a unit's RuntimeDirectory.

> 
> Sorry,
> 
> Lennart
> 

Thanks for the long explanations.

-Topi