Current pseudo-tty (pty) devices are owned by root and read-writableby everyone. The user of a pty-pair cannot changeownership/protections without being suid-root.This could be solved with a secure user-space daemon which runs asroot and does the actual creation of pty-pairs. Such a daemon wouldrequire modification to *every* programme that wants to use this newmechanism. It also slows down creation of pty-pairs.An alternative is to create a new open_pty() syscall which does muchthe same thing as the user-space daemon. Once again, this requiresmodifications to pty-handling programmes.The devfs solution allows a device driver to "tag" certain devicefiles so that when an unopened device is opened, the ownerships arechanged to the current euid and egid of the opening process, and theprotections are changed to the default registered by the driver. Whenthe device is closed ownership is set back to root and protections areset back to read-write for everybody. No programme need be changed.The devpts filesystem provides this auto-ownership feature for Unix98ptys. It doesn't support old-style pty devices, nor does it have allthe other features of devfs.Intelligent device managementDevfs implements a simple yet powerful protocol for communication witha device management daemon (devfsd) which runs in user space. It ispossible to send a message (either synchronously or asynchronously) todevfsd on any event, such as registration/unregistration of deviceentries, opening and closing devices, looking up inodes, scanningdirectories and more. This has many possibilities. Some of these arealready implemented. See:http://www.atnf.csiro.au/~rgooch/linux/Device entry registration events can be used by devfsd to changepermissions of newly-created device nodes. This is one mechanism tocontrol device permissions.Device entry registration/unregistration events can be used to runprogrammes or scripts. This can be used to provide automatic mountingof filesystems when a new block device media is inserted into thedrive.Asynchronous device open and close events can be used to implementclever permissions management. For example, the default permissions on/dev/dsp do not allow everybody to read from the device. This issensible, as you don't want some remote user recording what you say atyour console. However, the console user is also prevented fromrecording. This behaviour is not desirable. With asynchronous deviceopen and close events, you can have devfsd run a programme or scriptwhen console devices are opened to change the ownerships for *other*device nodes (such as /dev/dsp). On closure, you can run a differentscript to restore permissions. An advantage of this scheme overmodifying the C library tty handling is that this works even if yourprogramme crashes (how many times have you seen the utmp database withlingering entries for non-existent logins?).Synchronous device open events can be used to perform intelligentdevice access protections. Before the device driver open() method iscalled, the daemon must first validate the open attempt, by running anexternal programme or script. This is far more flexible than accesscontrol lists, as access can be determined on the basis of othersystem conditions instead of just the UID and GID.Inode lookup events can be used to authenticate module autoloadrequests. Instead of using kmod directly, the event is sent todevfsd which can implement an arbitrary authentication before loadingthe module itself.Inode lookup events can also be used to construct arbitrarynamespaces, without having to resort to populating devfs with symlinksto devices that don't exist.Speculative Device ScanningConsider an application (like cdparanoia) that wants to find allCD-ROM devices on the system (SCSI, IDE and other types), whether ornot their respective modules are loaded. The application mustspeculatively open certain device nodes (such as /dev/sr0 for the SCSICD-ROMs) in order to make sure the module is loaded. This requiresthat all Linux distributions follow the standard device naming scheme(last time I looked RedHat did things differently). Devfs solves thenaming problem.The same application also wants to see which devices are actuallyavailable on the system. With the existing system it needs to read the/dev directory and speculatively open each /dev/sr* device todetermine if the device exists or not. With a large /dev this is aninefficient operation, especially if there are many /dev/sr* nodes. Asolution like scsidev could reduce the number of /dev/sr* entries (butof course that also requires all that inefficient directory scanning).With devfs, the application can open the /dev/sr directory(which triggers the module autoloading if required), and proceed toread /dev/sr. Since only the available devices will haveentries, there are no inefficencies in directory scanning or deviceopenings.-----------------------------------------------------------------------------Who else does it?FreeBSD has a devfs implementation. Solaris and AIX each have apseudo-devfs (something akin to scsidev but for all devices, with someunspecified kernel support). BeOS, Plan9 and QNX also have it. SGI'sIRIX 6.4 and above also have a device filesystem.While we shouldn't just automatically do something because others doit, we should not ignore the work of others either. FreeBSD has a lotof competent people working on it, so their opinion should not beblithely ignored.-----------------------------------------------------------------------------How it worksRegistering device entriesFor every entry (device node) in a devfs-based /dev a driver must calldevfs_register(). This adds the name of the device entry, thefile_operations structure pointer and a few other things to aninternal table. Device entries may be added and removed at anytime. When a device entry is registered, it automagically appears inany mounted devfs'.Inode lookupWhen a lookup operation on an entry is performed and if there is nodriver information for that entry devfs will attempt to calldevfsd. If still no driver information can be found then a negativedentry is yielded and the next stage operation will be called by theVFS (such as create() or mknod() inode methods). If driver informationcan be found, an inode is created (if one does not exist already) andall is well.Manually creating device nodesThe mknod() method allows you to create an ordinary named pipe in thedevfs, or you can create a character or block special inode if onedoes not already exist. You may wish to create a character or blockspecial inode so that you can set permissions and ownership. Later, ifa device driver registers an entry with the same name, thepermissions, ownership and times are retained. This is how you can setthe protections on a device even before the driver is loaded. Once youcreate an inode it appears in the directory listing.Unregistering device entriesA device driver calls devfs_unregister() to unregister an entry.Chroot() gaols2.2.x kernelsThe semantics of inode creation are different when devfs is mountedwith the "explicit" option. Now, when a device entry is registered, itwill not appear until you use mknod() to create the device. It doesn'tmatter if you mknod() before or after the device is registered withdevfs_register(). The purpose of this behaviour is to supportchroot(2) gaols, where you want to mount a minimal devfs inside thegaol. Only the devices you specifically want to be available (throughyour mknod() setup) will be accessible.2.4.x kernelsAs of kernel 2.3.99, the VFS has had the ability to rebind parts ofthe global filesystem namespace into another part of the namespace.This now works even at the leaf-node level, which means thatindividual files and device nodes may be bound into other parts of thenamespace. This is like making links, but better, because it worksacross filesystems (unlike hard links) and works through chroot()gaols (unlike symbolic links).Because of these improvements to the VFS, the multi-mount capabilityin devfs is no longer needed. The administrator may create a minimaldevice tree inside a chroot(2) gaol by using VFS bindings. As thisprovides most of the features of the devfs multi-mount capability, Iremoved the multi-mount support code (after issuing an RFC). Thisyielded code size reductions and simplifications.If you want to construct a minimal chroot() gaol, the followingcommand should suffice:mount --bind /dev/null /gaol/dev/nullRepeat for other device nodes you want to expose. Simple!-----------------------------------------------------------------------------Operational issuesInstructions for the impatientNobody likes reading documentation. People just want to get in thereand play. So this section tells you quickly the steps you need to taketo run with devfs mounted over /dev. Skip these steps and you will endup with a nearly unbootable system. Subsequent sections describe theissues in more detail, and discuss non-essential configurationoptions.DevfsdOK, if you're reading this, I assume you want to play withdevfs. First you should ensure that /usr/src/linux contains arecent kernel source tree. Then you need to compile devfsd, the devicemanagement daemon, available athttp://www.atnf.csiro.au/~rgooch/linux/.Because the kernel has a naming schemewhich is quite different from the old naming scheme, you need toinstall devfsd so that software and configuration files that use theold naming scheme will not break.Compile and install devfsd. You will be provided with a defaultconfiguration file /etc/devfsd.conf which will providecompatibility symlinks for the old naming scheme. Don't change thisconfig file unless you know what you're doing. Even if you think youdo know what you're doing, don't change it until you've followed allthe steps below and booted a devfs-enabled system and verified that itworks.Now edit your main system boot script so that devfsd is started at thevery beginning (before any filesystemchecks). /etc/rc.d/rc.sysinit is often the main boot scripton systems with SysV-style boot scripts. On systems with BSD-styleboot scripts it is often /etc/rc. Also check/sbin/rc.NOTE that the line you put into the bootscript should be exactly:/sbin/devfsd /devDO NOT use some special daemon-launchingprogramme, otherwise the boot script may not wait for devfsd to finishinitialising.System LibrariesThere may still be some problems because of broken software makingassumptions about device names. In particular, some software does nothandle devices which are symbolic links. If you are running a libc 5based system, install libc 5.4.44 (if you have libc 5.4.46, go back tolibc 5.4.44, which is actually correct). If you are running a glibcbased system, make sure you have glibc 2.1.3 or later./etc/securettyPAM (Pluggable Authentication Modules) is supposed to be a flexiblemechanism for providing better user authentication and access toservices. Unfortunately, it's also fragile, complex and undocumented(check out RedHat 6.1, and probably other distributions as well). PAMhas problems with symbolic links. Append the following lines to your/etc/securetty file:vc/1vc/2vc/3vc/4vc/5vc/6vc/7vc/8This will not weaken security. If you have a version of util-linuxearlier than 2.10.h, please upgrade to 2.10.h or later. If youabsolutely cannot upgrade, then also append the following lines toyour /etc/securetty file:12345678This may potentially weaken security by allowing root logins over thenetwork (a password is still required, though). However, since thereare problems with dealing with symlinks, I'm suspicious of the levelof security offered in any case.XFree86While not essential, it's probably a good idea to upgrade to XFree864.0, as patches went in to make it more devfs-friendly. If you don't,you'll probably need to apply the following patch to/etc/security/console.perms so that ordinary users can runstartx. Note that not all distributions have this file (e.g. Debian),so if it's not present, don't worry about it.--- /etc/security/console.perms.orig    Sat Apr 17 16:26:47 1999 +++ /etc/security/console.perms Fri Feb 25 23:53:55 2000 @@ -14,7 +14,7 @@  # man 5 console.perms  # file classes -- these are regular expressions -<console>=tty[0-9][0-9]* :[0-9]\.[0-9] :[0-9] +<console>=tty[0-9][0-9]* vc/[0-9][0-9]* :[0-9]\.[0-9] :[0-9]  # device classes -- these are shell-style globs  <floppy>=/dev/fd[0-1]* If the patch does not apply, then change the line:<console>=tty[0-9][0-9]* :[0-9]\.[0-9] :[0-9]with:<console>=tty[0-9][0-9]* vc/[0-9][0-9]* :[0-9]\.[0-9] :[0-9]Disable devptsI've had a report of devpts mounted on /dev/pts not workingcorrectly. Since devfs will also manage /dev/pts, there is noneed to mount devpts as well. You should either edit your/etc/fstab so devpts is not mounted, or disable devpts fromyour kernel configuration.Unsupported driversNot all drivers have devfs support. If you depend on one of thesedrivers, you will need to create a script or tarfile that you can useat boot time to create device nodes as appropriate. There is asection which describes this. Anothersection lists the drivers which havedevfs support./dev/mouseMany disributions configure /dev/mouse to be the mouse devicefor XFree86 and GPM. I actually think this is a bad idea, because itadds another level of indirection. When looking at a config file, ifyou see /dev/mouse you're left wondering which mouseis being referred to. Hence I recommend putting the actual mousedevice (for example /dev/psaux) into your/etc/X11/XF86Config file (and similarly for the GPMconfiguration file).Alternatively, use the same technique used for unsupported driversdescribed above.The KernelFinally, you need to make sure devfs is compiled into your kernel. SetCONFIG_EXPERIMENTAL=y, CONFIG_DEVFS_FS=y and CONFIG_DEVFS_MOUNT=y byusing favourite configuration tool (i.e. make config ormake xconfig) and then make clean and then recompile your kernel and modules. At boot, devfs will be mounted onto /dev.If you encounter problems booting (for example if you forgot aconfiguration step), you can pass devfs=nomount at the kernelboot command line. This will prevent the kernel from mounting devfs atboot time onto /dev.In general, a kernel built with CONFIG_DEVFS_FS=y but without mountingdevfs onto /dev is completely safe, and requires noconfiguration changes. One exception to take note of is whenLABEL= directives are used in /etc/fstab. In thiscase you will be unable to boot properly. This is because themount(8) programme uses /proc/partitions as part ofthe volume label search process, and the device names it finds are notavailable, because setting CONFIG_DEVFS_FS=y changes the names in