Date: Tue, 19 Nov 2002 20:55:37 +0100 From: Poul-Henning Kamp <phk@critter.freebsd.dk> To: Robert Watson <rwatson@FreeBSD.ORG> Cc: Bruce Evans <bde@zeta.org.au>, Kris Kennaway <kris@obsecurity.org>, kip@eventdriven.org, current@FreeBSD.ORG Subject: Re: Device permissions with DEVFS Message-ID: <25060.1037735737@critter.freebsd.dk> In-Reply-To: Your message of "Tue, 19 Nov 2002 12:42:51 EST." <Pine.NEB.3.96L.1021119124035.60013B-100000@fledge.watson.org>
next in thread | previous in thread | raw e-mail | index | archive | help
In message <Pine.NEB.3.96L.1021119124035.60013B-100000@fledge.watson.org>, 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 phk@FreeBSD.ORG | 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 majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?25060.1037735737>