Skip site navigation (1)Skip section navigation (2)
Date:      Wed, 28 Nov 2001 18:35:04 +0100
From:      Poul-Henning Kamp <phk@critter.freebsd.dk>
To:        Robert Watson <rwatson@FreeBSD.ORG>
Cc:        Matthew Jacob <mjacob@feral.com>, Peter Wemm <peter@wemm.org>, Dima Dorfman <dima@trit.org>, arch@FreeBSD.ORG
Subject:   Re: Anybody working on devd? 
Message-ID:  <36373.1006968904@critter.freebsd.dk>
In-Reply-To: Your message of "Wed, 28 Nov 2001 11:51:39 EST." <Pine.NEB.3.96L.1011128113543.37721K-100000@fledge.watson.org> 

next in thread | previous in thread | raw e-mail | index | archive | help
In message <Pine.NEB.3.96L.1011128113543.37721K-100000@fledge.watson.org>, Robert 
Watson writes:
>On Mon, 26 Nov 2001, Matthew Jacob wrote:
>
>> > It would also be a place where a program could be called to respond to new
>> > nodes appearing in /dev for adjusting any permissions needed according
>> > to some sort of template system or something.  (But it would be a mistake
>> > to mix the two things up at this point, as the permissions setter is prime
>> > bikeshed material.  IMHO, provide the hooks first, then once we have the
>> > framework, then revisit the permissions).
>> 
>> It seems to me wrong to do 'adjustments'. Either you have a model that
>> trusts drivers to do the right thing when the call make_dev, or you
>> don't. 
>
>There are a couple of reasons why it would be desirable to allow devd (or
>devfsd, if you will) manage permissions.  They include:

Let me jump ahead a bit in the discussion here.

There are a number of questions to answer when a new device node appears,
the main two are:

	1. What mode/owner/group should it have.
	2. Should it appear in a particular devfs mount instance (ie: a jail)

While it may sound simple to make everything start out 0/0/0 and have devd
fix it up, it isn't simple once you start to implement it because now you
have devices in two states (those only devd can see and the real ones).
How do you recognize the authorized "devd" process from other processes ?
What about small/picobsd systems ?

My preferred solution therefore, is to add a rule-set facility to
devfs, so that for each mount-point, the policy can be expressed
in the kernel, by userland, if the defaults are not wanted.

I would imagine the rules [cw]ould look like this:

	class=disk owner=root group=wheel mode=0600
		# nonstandard everything
	name=uscanner* mode=666 chown chmod=0600
		# nonstandard mode.  On open chown to opening
		# process and mode 0600
	name=pty* hide
		# we don't want ptys in this jail.
	
In practice it will probably be devd which manages these lists.

The advantage to this scheme is that devd is not mandatory for small
systems, yet the policy is configurable.


-- 
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




Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?36373.1006968904>