Date: Mon, 16 Feb 1998 16:45:53 -0800 (PST) From: Julian Elischer <julian@whistle.com> To: current@FreeBSD.ORG Subject: Re: devfs persistence Message-ID: <Pine.BSF.3.95.980216153712.8949V-100000@current1.whistle.com> In-Reply-To: <199802162241.PAA00744@pluto.plutotech.com>
next in thread | previous in thread | raw e-mail | index | archive | help
firstly let me say I have always thought that
device persistance was a can of worms that is best solved
by LEAVING IT OUT!
having said that, I hear calls for some persistance.
I'm going to zip through this argument with my thoughts.
(having been out of it for 2 days)
On Mon, 16 Feb 1998, Justin T. Gibbs wrote:
> >Not entirely; you *don't* have the capacity to specify what a new
> >device node should look like when it's created. Because you're not
> >there waiting for it when it appears, there needs to be a mechanism
> >whereby you can specify in advance what it should look like.
>
> In todays system, if a "new device arrives", I hook it up to my machine,
> and expect to perform some amount of configuration to make that new device
> work. This could include adding kernel device support for it, adding the
> device to a cron job or other script, telling the user community about it,
> etc. In the world without DEVFS, this would also include the necessity of
> running MAKEDEV to create the node and, if the permissions weren't adequate,
> chmod/chown type operations. The only difference in this scenario with
> DEVFS is that the default node comes into existence automatically, but the
> user will still expect to have to modify permissions before the device is
> guaranteed to be completely usable. The only issue I see, is one of
> security with DEVFS. Some admins may not want new device arrivals to show
> up auto-magically.
Part of the 'charm' of a devfs is that you never have to do a
mknod because sensibly defaulted devices will turn up as th ehardware
does. At least in /dev. This may not be true in a chroot where
using -ono_new_dev in the mount is probably a good idea.
The persistance problem is more likely for a few devices
that the operator wants to do something funny with. I think that for
individual devices, once the operator has run 'chmod' on them they can
grow an inode in the backing layer. This unfortunatly means that all ttys
would grow such nodes.
There are problems with this however.
If a user renames the device, where is the info stored?
what if htere are multiple links?
The same problems hold for storing the info in files in general.
Is /dev/fd0 the same device as /dev/fd/fd0?
generally each node doesn't have a very clear idea of it's global name.
just it's name in the current directory, and it may have several of those.
>
> >The specific problem with using nothing but nodes behind the DEVFS
> >entries is that you can never provide for all the entries that might
> >appear without, you guessed it, a *script* that creates all these
> >backing nodes. Doesn't that sound familiar?
If it were to just replace MAKDEV, devfs would not be worth it.
but it comes from the many cleanups that become possible after it has
arrived that it derives it worth.
>
> This is not a problem unless there is a security issue, and I have already
> proposed a method for dealing with security issues with an option to only
> allow devices to show up that have a backing object. The user community
> already expects to have to modify the permissions of new device nodes if
> the defaults don't suit their needs... why is this any different.
That does beg the question of "how do you make the backing node
initially.." but that is soluble. How does a naive home-sysad
know what to do with the new devices? We need to assume that newly
arriving devices have secure parmissions.
>
> >> n?e?r?st[0-9]+
> >
> >Sure;
> >
> >nrst*
> >est*
> >rst*
I think regexp is too complicated..
a scanf() reader might be safer..
st%d
rst%d
nrst%d
>
> And st*, right? This will happily match stdout, stderr, and stdin.
what about devices in different directories.
this is tricky.
you don't know the full path of what you are
chasing down some of the time.
just the current component.
>
> And what if you don't want your rule to affect the control devices? I
> suppose that you will introduce some sort of ordering so that later entries
> override matches from previous ones? Now you have to provide an override
> that specifically restores the default permissions. What happens if
> someone adds a new device name that just happens to match one of your
> "prototypes" by mistake? You might never even notice this, but the
> security ramifications could be large. What happens if you attempt to
> chmod/chown a file that has a protoype? I think the user would be really
> confused to find those operations ineffective. The more I look at this
> prototype stuff, the more I dislike it.
I'm kinda unsure about it myself. I can see that some way of setting the
defaults for a driver to use might be good. But I wonder if it wouldn't be
better achieved by directly communicating thin information at the same
time that we load the driver? I can see a mechanism for loading the info.
(similar to quotas (mount -tdevfs -opermfile=/etc/devperms,nonewdevs devfs
/dev) but remember that the initial mount is done by init() so init
would have to know the name for the permfile. The tricky bit is trying to
match devices to entries in the file. firstly: in devfs_lookup() we only
really easily know one companent of the name.. the one we are presently
working on. We can probably work out the rest but it's not immediatly
obviousi (getwd())?, and what if the same device is really 2 links to the
same node.
>
> >I'd be more worried about tty[pqr]* to be honest. Regardless, a simple,
> >generalised glob matcher would find consumers in quite a few parts of
> >the system (SCSI/ATA/ATAPI quirk matching just for starters).
true, but that is a buch more controlled situation,
>
> These don't include character class globbing which I think you'd need here
> (see my stdin, etc. example).
>
> >> Most (all?) areas of the kernel never directly interpret user produced
> >> data. Sure, the kernel moves user data, copies it, sends it to a device,
> >> etc, but the kernel is not currently prone to the typical buffer overflows
> >> and other attacks that you usually see in userland provided services.
> >
> >So how is the proposed interface any different?
>
> You're talking about feeding an arbitrary file into a kernel provided
> parser. I think I'll use /bin/cat as my prototype file and see what
> happens to my system. What happens if the filesystem, and your info
> file, gets trashed?
maybe we delay all file permission changes till we do a mount -u
which is done after single user mode..
so that in single user mode everything is default.
>
> >> Sounds much more complicated and space consumptive than it has to be.
> >
> And saying, "If you mount your DEVFS on a directory that just happens to
> have a 'devinfo' file, you get magical DEVFS properties", is intuitive?
If you specified the file in the mount options it get's more intuitive.
but this is not the same as persistance, which is making the results of
setattr() stick across reboots. do we watn reanmes to stick too?
that would be REAL persistance. Personally I think that
making the rule simple.. ("DEVFS is not persistant") it makes it a lot
more intuitive.
>
> >> When would you be duplicating the node permissions into a new mountpoint?
> >
> >Anytime you wanted to mount the devfs somewhere else and have it behave
> >like it currently does.
certainly I can see that you may want to stop new arrivals.
it would be easiest to just allow mount_devfs to know about a file
to use as a template.
>
> Which happens when?? In either scenario, you may end up leaving trash in
> the mount point. Of course, in the current system you have to have a
> file per node anyway...
> >> I would say that 99.99% of our user community never modifies the
> >> permissions from the default that MAKEDEV creates. They seem to be
> >> able to use their devices just fine.
I'd say it's 1% who actually want the permissions to STICK.
> The first person I heard voice a desire to do this was PHK. I like Poul a
> lot, but I don't think we should put every feature Poul wants into FreeBSD.
> You have since taken on his argument too, but who else? The other people
> I've heard in this discussion have voiced concerns about being able to
> do what they can do today without DEVFS, with DEVFS.
Probably you first heard it from ME rather than Poul :)
>
> >> The kernel provides the default state for nodes. When a user first
> >> encounters DEVFS, they will not immediately think to alter some prototype
> >> file, so as system designers, we have to ensure that the default state of
> >> the system is fairly secure. This has been the policy for MAKEDEV entries
> >> since before I joined the project.
> >
> >Sure, and I was never proposing that the default state would, or
> >should, be insecure. My point was simply that you are suggesting that
> >there should be *no* configurable policy for new nodes. This is
> >inferior to the current methodology, and unacceptable to more than a
> >few people.
The trouble with new nodes is that you really can't predict REALLY new
nodes. No matter WHAT the mechanism.
>
> This is not what I have proposed. New nodes are configurable in that
> you can configure the system to either show them or not. This gives
> you the option to get exactly the same functionality as the current
> system.
is a permanent rm required for persistance?
> >
> >The wildcard is never available to anyone other than the shell, so the
> >point is moot.
> >
> >However, why are you opposed to providing a mechanism whereby they
> >*can* provide a prototype to effect this removal? Do you have an
> >alternative proposal that is capable of achieving this?
>
> I already proposed one. The "backing store only" option prevents new
> device arrival from perturbing the "state of the world" the admin
> setup. The only difference is that you must explicitly specify the
> devices you want, not the devices you don't want.
I think this is an easier problem to solve.
I mentionned 3 mount options in an easier message.
>
> >> If you insist that some kind of prototyping scheme is still necessary, take
> >> care of it using a daemon forked by mount_devfs that shares a socket with
> >> DEVFS in the kernel and is notified of mount and arrival changes so it can
> >> modify the permissions.
> >
> >We've been down this path before. A daemon has a number of fundamental
> >flaws:
> >
> > - If you expect the daemon to take care of all permissions
>
> Which I don't.
>
> > , and you
> > accept that local policy may want to be arbitrarily strict, then
> > new nodes have to arrive with no permissions whatsoever.
no, they can start with strict permissions.
>
> Nope. The mount mode could specify that no new node can be made visible
> until after the daemon has been notified and acked the notification. I
> could easily envision a system where you only go into "daemon mode" when a
> specific mount option is specified. While the system is in SU mode, you
> rely on whatever backing objects exist to modify permissions but still
> display all devices. When you transition to MU, you "mount -u" DEVFS to
> start up the daemon which applies any prototypes you have specified and
> starts up this protocol.
Sound idea, but ....
>
> > However
> > this means that the daemon has to be running before the system can
> > come up (impossible), and that any failure in the daemon will
> > effectively kill the system.
>
> Use some imagination. The protocol can be specified such that the worst
> case scenario is that new device nodes do not show up for a DEVFS that is
> configured to rely on the daemon. The kernel should never have to block
> FS requests because the daemon died.
As I said before, the system could certainly run without whatever this
mechanism is..
>
> > - A userspace daemon would be inefficient for embedded systems, which
> > is one of the prime targets for DEVFS.
>
> Embedded systems should directly modify the kernel source to get the
> default permissions the way they want. I don't buy the inefficiency
> argument either. Device arrival events should be rare. How often do
> you expect them to happen? Once a second is still a relative eternity
> between arrivals.
embedded systes probably don't have arriving devices at all.
>
> > - The coupling between a set of device nodes and the backing store for
> > their attributes is looser than might be desired.
>
> Actually it is tightly coupled since you don't need the daemon or parser
> to get back all of the setting you've set in the past.
I'm losing track here..
I assume this means the actual persistance being achieved via backing
nodes is tighter.. (agreed).
>
> >> I think that it should only act as surrogate for
> >> performing rm/chmod/chown operations on devices that match a regexp, but
> >> that the persistent file store should still be handled as easy to manage
> >> underlying files. This means that should the daemon die, your DEVFS still
> >> retains the last set of permissions it was given and no reliance on the
> >> user daemon to perform any DEVFS operation is required.
> >
> >This presumes that your DEVFS is mounted on persistent storage.
>
> It only assumes a persistent backing store if you want permissions to
> be retained across reboots. Of course, your scheme also has this
> requirement since the permissions have to be recorded somewhere.
>
> >Basically, you're agreeing with everything that's been proposed, except
> >that you want to put the rule parser in a daemon.
>
> I still severely question the need for this functionality, but if it's
> determined that it must exist, I don't want to see the kernel bloated
> to provide it.
As I said I qustion th eneed for kernel based persistance at all.
it just confuses the HECK out of the picture.
just look at this argument between two intelligent people on the topic..
>
> >Which just puts the
> >bloat in swap space, along with yet another copy of large parts of the C
> >library.
>
> Disk space is still much cheaper than RAM.
>
> >I don't buy the trivial size reduction as a benefit outweighing the
> >drawbacks, and in the few cases where bloat is actually an issue, the
> >size of the daemon's executable would be more of a penalty than the
> >extra code growth in the kernel.
>
> The kernel can't be swapped out.
>
> --
> Justin
>
>
>
To Unsubscribe: send mail to majordomo@FreeBSD.org
with "unsubscribe freebsd-current" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?Pine.BSF.3.95.980216153712.8949V-100000>