In message <[EMAIL PROTECTED]>, Robe rt Watson writes:
>> > No, the default permissions are specified in the driver source code >> > via make_dev(). >> >> The drivers only get the magic numbers for uids and gids from a central >> file. This is bad enough. I think all devices should have ownership >> root:wheel and mode 0600, but that would increase the problems with >> non-persistent attributes. devfs(8) may be able to handle this now. > >I have to say that the ownership issue has been a pet peeve of mine for >some time: I would really like the kernel to know about exactly two magic >id values: uid 0 (suser uid, default uid, default devfs owner), and gid 0 >(default gid, default devfs owner). Hard-coding of other non-0 values in >the kernel leads to many potential (and real) problems. While you are right in principle, I think we should not overengineer here. People who are likely to give operator a different gid are also very likely to compile their own kernels (which I admit does not solve the 3rd party KLD issue but...) Devfs(8) provides a mechanism for setting the m/o/g and a few other attributes, and it would in theory be possible to let all devices come up 0/0/0 and have /etc/rc set the policy from /etc/rc. This has the disadvantage that the /etc/rc mechanism needs to be extensible so that 3rd party drivers can hook in their policy. Some will argue that this is a move away from TRT and I might find myself under that banner once I see a prototype. So while this would strictly speaking be more correct, it is also yet a bunch of files for embedded systems need to include on their media, and I think that is too high a price for such a small incremental (independent of size) change in correctness. I think we should stick to the current slightly "hackish" way, possibly with the modification that the security-officer gang gets to rule what exact m/o/g devices in the FreeBSD cvs tree should have. -- Poul-Henning Kamp | UNIX since Zilog Zeus 3.20 [EMAIL PROTECTED] | TCP/IP since RFC 956 FreeBSD committer | BSD since 4.3-tahoe Never attribute to malice what can adequately be explained by incompetence. To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message