Date: Wed, 6 Jan 1999 16:31:16 -0000 From: Paul Richards <paul@originative.co.uk> To: freebsd-arch@FreeBSD.ORG Subject: RE: DEVFS, the time has come... Message-ID: <E40CBF0361C7D111914000C0F0303D108859@OCTOPUS>
next in thread | raw e-mail | index | archive | help
I think first of all that it's worth clarifying that *everyone" is in favour of persistence. No-one is advocating that policy should not be defined by the admin. The discussion is and should centre on how local policy is implemented, should it be done in the kernel or in userland. Those in favour of "non-persistence" are simply advocating that userland tools, such as scripts, be used to achieve persistence rather than having it built in to devfs itself. The arguments in favour of persistence of some form are largely won I think but I can go over them if people don't think so. I'd like to hear good arguments against putting persistence into the kernel since the userland solutions all have shortcomings that we're fighting to cludge around and will almost certainly need some kernel support in any case. I personally think that given that /dev becomes a kernel function creating /dev entries should also be a kernel function in their entirety and not simply in part. The only argument I can recall against a kernel implementation of policy is the need to maintain some form of device database. I don't see what the big deal is with this since it would have to exist in some form regardless of the implementation. My arguments against an userland implementation are largely based on security and robustness issues. >From a security point of view, unless policy is implemented at the time that the device is instantiated then a race condition exists between the creation of the dev entry and the application of the policy. The script solution is a non-starter since it takes no account of dynamically created devices after boot so I'll focus on my concerns for a daemon based solution. If devices are created with default perms (possibly based on class) then there is a clear race condition between the device coming into existence and the daemon running. This may or may not provide the potential for a security breach. To safeguard against this possibility the alternative is to create the device with 000 perms so that no possibility of a security hole exists. However, this creates a chicken/egg situation at boot since the root filesystem would need to be accessible by root or you're not going to get very far. To get around this you're going to have to have some form of kernel support for setting initial device perms or you won't be able to bring the machine up. This applies regardless of what solution you adopt for providing persistence of local policy. If you're going to have some mechanism in the kernel for specifying initial /dev perms at boot then why not just complete the implementation and make the kernel responsible for setting perms at other times. >From a robustness point of view, I'd be very concerned about relying on a userland process for maintaining /dev. If that daemon should not start or at some later point fall over then you may find you have a hard time getting a useable system. As a worst case scenario, should the on-disk copy of the image get damaged in any way then at next boot you'll have a totally screwed system, this is true of other binaries as well of course but I think we should minimise such dependencies not increase them. Personally, I can't see any way of preventing race conditions without applying policy when the device is created and that will require a kernel implementation of persistence. Paul. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?E40CBF0361C7D111914000C0F0303D108859>