On 01/26/15 16:13, Lennart Poettering wrote: > On Sat, 24.01.15 10:09, Topi Miettinen (toiwo...@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 _______________________________________________ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
