Date: Fri, 01 Jan 1999 22:12:23 -0700 From: Warner Losh <imp@village.org> To: freebsd-arch@FreeBSD.ORG Subject: Re: DEVFS, the time has come... Message-ID: <199901020512.WAA09287@harmony.village.org> In-Reply-To: Your message of "Fri, 01 Jan 1999 20:55:55 PST." <199901020455.UAA01211@dingo.cdrom.com> References: <199901020455.UAA01211@dingo.cdrom.com>
next in thread | previous in thread | raw e-mail | index | archive | help
In message <199901020455.UAA01211@dingo.cdrom.com> Mike Smith writes: > I was just discussing this with Eivind; I think that we can comfortably > cover every set of requirements with: > > - a kernel-wide default owner/group/permissions for new nodes, which > can be overridden by the device driver in response to eg. > configuration arguments or device-specific concerns. This may work OK, but there needs to be some way to have an effective infrastructure to allow this to be changed when the devices come and go. It still doesn't answer the problems that I wrote about in earlier messages. Namely if I chown imp /dev/mouse, and then i unplug the mouse and plug it back in, what should happen? Should it revert to root ownership? Or should it revert to imp ownership. I think the latter. What permissions should be retained? This is a thorny issue that we cannot afford to punt on in the long term. We need to have mechanisms in place for dealing with exactly this sort of thing. EE says: > [My only concern with a non-persistent DEVFS is the permissions on > device nodes that appear due to an event (e.g, a card insertion), and > I think the can be adequately addressed by having a flag for a DEVFS > mount that stop new nodes from automatically appearing in that > instance of DEVFS. -EE] EE also says: > [The problem of insecure device-creations can be solved by defaulting > to not create devices dynamically after boot. -EE] I don't think that solves any problems. You just make devices useless then. If I had forgotten to plug my USB mouse in on boot, I shouldn't have to reboot to get it. Also, if I unplug my mouse after it has been chown'd to me, and then plug it back in, I should still own the mouse. In a static world the rc.dev script is an excellent solution, but with devices coming and going over time a better solution is needed. While the static solution would be better than no solution at all, there needs to be some thought as to what the long term solutions to this problem is going to be as things get more and more dynamic. Disallowing dynamic creation of device nodes in a devfs mounted system seems counterproductive to me. I'd go farther and say that I don't think that a devfs option to disable new nodes appearing is even acceptable. It must not be required to have a secure system. When the kernel boots, any card devices are not detected. It is only after pccardd starts that they are detected and configured in the kernel. This could introduce a race condition (did the dev script run before or after this device was added). pccardd doesn't even guarantee when it will get around to dealing with cards in the PCMCIA bus when the system boots. It is started way late in the game. Much later than any rc.dev script would run. Also, with CAM new devices can come and go at any time. I can rescan the SCSI bus and have the scanner or tape or whatever I forgot to turn on at boot time come to life, or that I plugged into the SCSI bus after boot for the purposes of gaming or backups. There needs to be some standard, sane way of dealing with these issues and a plan for them over the long haul. While the next iteration of DEVFS need not address these issues, they will need to be addressed before DEVFS can become default, especially the security ones. The biggest problem with the current incarnation of devfs is its inability to deal with devices being added from interrupt context. Once that is solved, we'd have a good version 0 of devfs. Until a mechanism can be put into place for dealing with these thorny issues, making it default (aka version 1) will need to wait. Warner 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?199901020512.WAA09287>