[RFC] Removal of devfs multi-mount feature

From: Richard Gooch (rgooch@ras.ucalgary.ca)
Date: Sat Jun 03 2000 - 11:13:41 EST


  Hi, all. The recent work by Al Viro on VFS bindings opens up the
possibility of removing the built-in multi-mount facility in devfs.
I'd like to discuss the pros and cons and get some feedback.

As some of you are aware, devfs may be mounted multiple times, with
the option of *not* exposing device entries in a mounted devfs until
the sysadmin does mknod(2). Permissions and ownerships are maintained
separately for each mounted devfs.

This multi-mount feature is designed with chroot gaols in mind, where
you may want to expose a very limited number of device nodes in a
gaol.

With VFS bindings, it is possible to bind individual files (the
original design only bound directories, IIRC), thus providing a
similar feature that the devfs multi-mount facility does. What would
be lost is the ability to independently change permissions on device
nodes in each chroot gaol; permissions would be shared. At some point
in the future VFS bindings may allow us to inherit permissions from
the VFS mount, which would mean all devices in a gaol would have the
same permissions. But such a development may never happen, so bear
that in mind.

My inclination is to just rely on VFS bindings, as it should be
sufficiently flexible (I hope) and it simplifies the devfs code.

I'd like to get feedback from people who set up chroot gaols (or at
least those people who think and care about them:-) on whether
changing from the current built-in devfs multi-mount feature to just
relying on VFS bindings (and thus less flexibilty with controlling
permissions) is a problem or not.

                                Regards,

                                        Richard....
Permanent: rgooch@atnf.csiro.au
Current: rgooch@ras.ucalgary.ca

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.rutgers.edu
Please read the FAQ at http://www.tux.org/lkml/



This archive was generated by hypermail 2b29 : Wed Jun 07 2000 - 21:00:17 EST