Date: Sat, 02 Jan 1999 11:36:45 +0100 From: Poul-Henning Kamp <phk@critter.freebsd.dk> To: Chuck Robey <chuckr@mat.net> Cc: arch@FreeBSD.ORG Subject: Re: DEVFS, the time has come... Message-ID: <6040.915273405@critter.freebsd.dk> In-Reply-To: Your message of "Fri, 01 Jan 1999 18:55:40 EST." <Pine.BSF.4.05.9901011829540.335-100000@picnic.mat.net>
next in thread | previous in thread | raw e-mail | index | archive | help
I've gathered all my replies into this email to try to keep the focus.
> From: Chuck Robey <chuckr@mat.net>
>
> First, Poul, will you agree that the opinion of the great majority of
> developers want persistence?
No, I will not.
I think the great majority of developers hasn't even thought about
the pro-et-contra of the situation, or as the emails here convinced
me, mixes the issue up with other more technical issues which have
solutions in both cases.
> To take it one step further, wasn't one of the main reasons for the
> non-acceptance of our last devfs (not the only reason, but a main
> reason) it's lack of a strategy for implementing persistence?
There were more reasons than that, but please leave that out of
the current discussion, that is not the subject we're trying to
settle.
> As such, default values could very easily be handled, couldn't they,
> in a number of different ways, in fact. It could be done in ASCII
> files (RO files, not modifiable), or the drivers themselves could
> store such stuff, and regurgitate it on ioctl calls, right? It
> could even be done via sysctl, although that strikes me as a bit
> weird.
If you look at your suggestion, will you not agree with me that this
sounds like a bunch of gross hacks which would violate POLA big time ?
> From: J Wunsch <j@uriah.heep.sax.de>
>
>> NON-PERSISTENT DEVFS:
>
> I don't see any form of an implementation for `whiteout' and
> `undelete' so far.
>
> Well, one question sideways: does this mean all the problems with
> disks entered after boot-time have been resolved in the existing
> implementation?
Please disregard the current implementation and its limitations and
focus on the hot spot of this discussion.
>> How about the case where people try out some gadget, forgets about
>> it for a number of months and buy some other gadget instead which
>> the same driver recognizes, then suddenly some old stuff appears
>> out of nowhere which may not even apply to that device, and since
>> the device is there in the database, not even the device driver
>> gets a chance to say what it feels about the issue ?
>
> In AIX, it would have become instance #1 for the new gadget, with
> keeping the old instance #0 in mind for eternity. :-)
Unless of course you put it in the same slot :-(
Yes, I think AIX did as good a job on persistence as you can do,
modulus a few representation issues, and that is one of the reasons
why I don't want persistence. The fact that the IBM subsidiary who
made the ATM adapter for the RS/6K didn't register their hardware
at all and when told so said "Sorry that scheme sucks and we're not
going to burn our users with it" certainly made an impression on me.
> From: Mike Smith <mike@smith.net.au>
>
>> I don't particularly like the idea that you can thus destroy a device
>> access point accidentally. I'd like to see some method for the
>> sysadmin to tell the kernel to `go back and re-establish its idea of
>> the DEVFS'.
>
> My personal preference for this is for it to be handled by mknod. The
> mknod(2) syscall would un-whiteout a device node (or nodes), allowing
> you to bring them back from the dead (perhaps modulo securelevel).
But if you think about chroot for a moment, it will be obvious to
you that we need a way to hide (whiteout) and to destroy for good
(unlink) a node. You would not want it to be possible to bring
them back in a chroot jail. Agreed, that could also be handled
by the same mount option which says "show me no new devices". Lets
bag this point as an implementation issue. It is not material to
the persistence/non-persistence debate.
> From: Warner Losh <imp@village.org>
>
> What we absolutely must not do is to create devices that will cause
> the security of the system to be compromised. This would be
> absolutely disasterous from a PR point of view.
Agreed. This is where I think a persistent DEVFS has a big problem
because old stuff will be kept around. We have no way of knowing
if a particular device is gone for good or will come back. And
we have no way to know, if it comes back, if the users considers
it the same device in the first place.
> In message <199901020116.RAA03885@dingo.cdrom.com> Mike Smith writes:
>
> Even if we had good documentation, I think it will still violate POLA.
I think /dev in its current form is a violation of POLA, at least
when you accidentially create a large file called /dev/rsy0...
> We must remember that rc.* is not an acceptible solution because
> devices can come and go.
Devices which come and go will need a daemon anyway to swing them
into action (mount, ifconfig and so on).
I have deliberately kept this daemon out of the picture, because
it raises another bunch of sensitive issues and it does not depend
on the persistence or not of the underlying DEVFS. I have detailed
a little bit about it at the end of this email, but please lets
try to stay focused in this discussion.
>From a security point of view, the new devices will come up
000/root/wheel in a non-persistent DEVFS, and whatever happens to
be in the persistence database in a persistent DEVFS.
> From: Warner Losh <imp@village.org>
>
> In another message I went over some of my security concerns, others
> have raised them as well. Basically, I don't want to see anything
> which would lessen the security of the system.
This is an important point also for me, and it is where I am very
afraid of this dormant stuff in the persistence database.
> From: Nate Williams <nate@mt.sri.com>
>
> To counter Joerg's 'not bothered by non-persistent DEVFS', I'd have to
> say that my experience with Solaris has been less than enthusiastic.
> Note, it only dealt with one device (the tape drive), but it was a pain
> in the butt.
I think there is widespread agreement that Solaris got it about as wrong
as they could.
-------------------
I would like to ask you all to refocus on the POLA part of the discussion
here, since all the other stuff you have raised all have technical (if in
some cases cumbersome) solutions for both kinds of DEVFS.
Obviously if we implement the daemon-assisted approach right away,
we could make it a switch if we wanted persistence, but I think that
would be asking for trouble BIG time. Then some systems would have it
and others not, and 3rd party developers would be screwed badly.
The question remains more or less:
Do we want a "chmod 764 /dev/foo" to be persistent over reboot,
despite the significant amount of code it takes, and the potential
to pop out of the blue six months later and bite people ?
So far I hear the following clear opinion:
Joerg: non-persistent
DavidG: non-persistent
Poul-Henning: non-persistent
I think I hear Mike Smith saying:
"I want persistence for persistence sake"
And I hear a number of people who don't really care that much, as
long as a number of concerns are addressed (although some seem to
think that persistence will be better able to address these issues).
Correct me if I'm wrong.
------------------------------------------------------------------------------
Let me fill on some background stuff on the daemon.
A dynamic device daemon ("devd"), can of course also handle the
static devices, they're no different, they're just not as dynamic.
The simplest daemon will spot a change in the /dev tree, and go
look for a command:
/etc/dev.d/$devicename$unit
failing that it will look for:
/etc/dev.d/$devicename
failing that it will look for:
/etc/dev.d/default
having found it it will:
$command {come|go} $devicename $unit
So our /etc/dev.rc has become /etc/dev.d/default and contains
a big switch (sounds like MAKEDEV, doesn't it ?)
The applicable command can and should obviously set the mode/owner/group
of the /dev nodes along with other stuff (ifconfig/mount...) it
might do.
Now, problems: Imagine a ZIP drive. Plugging it in is easy, and
it gets mounted and used. Now I unplug it. The device node cannot
disappear until it has been unmounted (last close) obviously, so
the device driver will have to send a signal to the devd process
saying "I'm toast", so that devd can umount (-force) which will
make the device node disappear (on last close).
So the "go away" event is NOT triggered by the disappearance of the
device node in /dev, that complicates matters a bit. This could
be handled by a call from the device driver to the DEVFS informing
of the wish to disappear once cleanup is done. Obviously a non-open
device can just pack up and leave.
As I said above, this doesn't really have any thing to do with the
persistence or not issue, so just consider this background info, and
lets not start a debate about this stuff yet. You will get your
chance on this stuff later on, don't worry :-)
--
Poul-Henning Kamp FreeBSD coreteam member
phk@FreeBSD.ORG "Real hackers run -current on their laptop."
"ttyv0" -- What UNIX calls a $20K state-of-the-art, 3D, hi-res color terminal
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?6040.915273405>