On Sat, 24.01.15 10:09, Topi Miettinen ([email protected]) 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. 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... Sorry, Lennart -- Lennart Poettering, Red Hat _______________________________________________ systemd-devel mailing list [email protected] http://lists.freedesktop.org/mailman/listinfo/systemd-devel
