Darren J Moffat wrote: > James Carlson wrote: >> As a way to illustrate the point: suppose we had a new kind of SCSI >> drive that included encryption. Suppose that drive required new >> commands when first connected in order to establish the key in use >> (the "security relationship" between the drive and host). Would we >> need or want a new daemon to handle that? Or would it more naturally >> be an extension of the existing devices framework? > > Thats a good example and one I've actually been doing some thinking > on. I think actually it might be a yes to both. We might need a new > daemon to do some key management tasks but we would certainly be > plugging into the existing devices framework. > >> What I'm concerned about here is that having a separate daemon to >> manage a group of devices will likely lead to even more confusion in >> the whole device allocation and permissions area. > > I agree with Jim here in general. > > I would have expected the WUSB to be adding a plugin to > /usr/lib/devfsadm/linkmod/ I will investigate your suggested method. I've ever taken a quick look that long time ago and found most of the plugins dealt with device links. Do you know if there's some project using the devfsadm plugin mechanism to handle device security?
Thanks, Lei Chen > > The really important thing here is to make sure that all the existing > frameworks continue to work since this is really a transport layer > change. Compare this to adding IPsec below TCP, applications didn't > have to change and IPsec is part of IP. > >
