From owner-freebsd-arch Wed Nov 28 10: 0:15 2001 Delivered-To: freebsd-arch@freebsd.org Received: from critter.freebsd.dk (critter.freebsd.dk [212.242.86.163]) by hub.freebsd.org (Postfix) with ESMTP id 4530537B41D; Wed, 28 Nov 2001 10:00:03 -0800 (PST) Received: from critter.freebsd.dk (localhost [127.0.0.1]) by critter.freebsd.dk (8.11.6/8.11.6) with ESMTP id fASHwlV37074; Wed, 28 Nov 2001 18:58:47 +0100 (CET) (envelope-from phk@critter.freebsd.dk) To: Robert Watson Cc: mjacob@feral.com, Peter Wemm , Dima Dorfman , arch@FreeBSD.ORG Subject: Re: Anybody working on devd? In-Reply-To: Your message of "Wed, 28 Nov 2001 12:55:41 EST." Date: Wed, 28 Nov 2001 18:58:47 +0100 Message-ID: <37072.1006970327@critter.freebsd.dk> From: Poul-Henning Kamp Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG In message , Robert Watson writes: >I'm not opposed to a 'first stab', but in the case of picobsd, I suspect >0/0 0600 would be just fine. I think that this "conservative policy" >viewpoint actually makes a fair amount of sense: we start up init with a >high level of privilege, and start up devices protected tightly, but >accessible via privilege (which init has). Well, we use the same as we had in MAKEDEV for "conservative". > What I would like to avoid is >kernel code knowing much about non-0 uids and gids. I agree this is not nice, but given the rule-system I proposed this would be a non-issue. >When dealing with NFS >and multiple platforms, you almost immediately run into different use of >those other uids and gids. Well, in a devfs context this is a non-issue since devices are local in NFS. >In general, with the exception of device owner >initialization, the kernel knows nothing about uids except for 0 and >VNONVAL. In the device code, we find a lot of #define's that teach device >drivers things that are usually defined in the password file. Please read my email about the proposal for rules, that would move this back to the password file. >Regarding the multiple instantiation--it does raise an interesting >question. Should the protections be on the device "objects" or on the >file system representations? Nope, it is on the file system representation. No doubt about that from the author of jail. -- 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-arch" in the body of the message