From owner-freebsd-current Tue Nov 19 11:55:52 2002 Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 03C6B37B401; Tue, 19 Nov 2002 11:55:51 -0800 (PST) Received: from critter.freebsd.dk (critter.freebsd.dk [212.242.86.163]) by mx1.FreeBSD.org (Postfix) with ESMTP id A7A6443E9E; Tue, 19 Nov 2002 11:55:49 -0800 (PST) (envelope-from phk@critter.freebsd.dk) Received: from critter.freebsd.dk (localhost [127.0.0.1]) by critter.freebsd.dk (8.12.6/8.12.6) with ESMTP id gAJJtbbq025061; Tue, 19 Nov 2002 20:55:37 +0100 (CET) (envelope-from phk@critter.freebsd.dk) To: Robert Watson Cc: Bruce Evans , Kris Kennaway , kip@eventdriven.org, current@FreeBSD.ORG Subject: Re: Device permissions with DEVFS In-Reply-To: Your message of "Tue, 19 Nov 2002 12:42:51 EST." Date: Tue, 19 Nov 2002 20:55:37 +0100 Message-ID: <25060.1037735737@critter.freebsd.dk> From: Poul-Henning Kamp Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG In message , 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