Skip site navigation (1)Skip section navigation (2)
Date:      Wed, 28 Nov 2001 12:25:38 -0800
From:      Bakul Shah <bakul@bitblocks.com>
To:        Poul-Henning Kamp <phk@critter.freebsd.dk>
Cc:        mjacob@feral.com, arch@FreeBSD.ORG
Subject:   Re: Anybody working on devd? 
Message-ID:  <200111282025.PAA03173@wellington.cnchost.com>
In-Reply-To: Your message of "Wed, 28 Nov 2001 19:41:35 %2B0100." <38091.1006972895@critter.freebsd.dk> 

next in thread | previous in thread | raw e-mail | index | archive | help
> >There's a race between some joblow driver setting completely loose permissions
> >and devd setting the policy based ones. This is a security hole. This is what
> >I meant by "either you trust the driver or you don't". The consensus here is
> >that "we don't".
> >
> >Therefore, internally make_dev uses 0/0 600 as default- not settable by
> >driver. The default policy for picobsd would be 666 I assume.
> 
> Guys,
> 
> Witht rules system I'm proposing you can have "any of the above"
> if you want.
> 
> No matter which single one we choose, it is inadequate for one or
> more of the other cases.
> 
> It needs to be possible to specify a policy and the default policy
> if you don't do that need to be sensible.
> 
> If anyone has a better suggestion how to express the policy than
> by sticking rules like I proposed into the kernel from a userland
> program, I'm all ears...

May be device nodes should be created by a user process, not
any kernel entity, so that the process can implement any
policy it wants.  This is what we did 20 years back (at
Fortune Systems) and I still prefer it.  A syscall queried
each device driver which returned a list of supported
canonical device names and major+minor for each (IIRC, a
printf string like "tty%d" and a range of acceptable
numbers).  A user program run at boot time created the actual
indoes, create links (e.g.  cuaa0 for ttyd0), etc.

Back then devices only appeared at boot time so this was good
enough.  Now I'd probably create a notification facility
accessed via a socket or something (like the one for route
add/change/deletes).  A daemon (devd?) can be notified of
appearance/disappearance events of devices and create/delete
appropriate device nodes as well as perform any auxiliary
actions such as automounting/dismounting.  I believe such a
daemon can be taught to create the right nodes for any jail
(and no it doesn't have to run in one) assuming it is told
where each jail's devices live.  You can also start devd in a
jail if you wish since any number of processes can listen
for device events.

At my last company we needed something similar -- depending
on which io cards were plugged in the router we needed to
create different kinds of and number of network interfaces
(the actual numbers were far higher than your typical freebsd
system).  We then needed to download firmware on certain
boards + we wanted each properly working interface to be
automatically configured in a particular way.  We also needed
to `watch' all IO cards, power supplies, fans and backplanes
to handle any failure and apply appropriate switch over.  We
certainly did not want the kernel to directly deal with all
this mess.  Even the daemon watching device events did not do
it all -- it called on other programs as necessary.

So I think a user level devd + a device change notification
scheme makes a lot of sense compared to sticking policy in
the kernel.

FWIW.

-- bakul

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?200111282025.PAA03173>