X-Git-Url: http://www.chiark.greenend.org.uk/ucgi/~ianmdlvl/git?p=elogind.git;a=blobdiff_plain;f=FAQ;h=45337bf635174adb2d1d2cc53d17653439614396;hp=d9aebde0da6e75adfb94421b14b09a648733d551;hb=396bb4c3d33dfd68c5817da5e03251fbd82e2713;hpb=10a479f5e6df7010a47f1edfab8173de85a34d0d

diff --git a/FAQ b/FAQ
index d9aebde0d..45337bf63 100644
--- a/FAQ
+++ b/FAQ
@@ -23,7 +23,7 @@ A: To quote Al Viro (Linux VFS kernel maintainer):
 	- the former had stayed around for many months with maintainer
 	  claiming that everything works fine
 	- the latter had stayed, period.
-	- the devfs maintainer/author disappeared and stoped maintaining
+	- the devfs maintainer/author disappeared and stopped maintaining
 	  the code.
 
 Q: But udev will not automatically load a driver if a /dev node is opened
@@ -44,10 +44,16 @@ A: Such a functionality isn't needed on a properly configured system. All
    hardware in memory, then use something else to manage your modules
    (scripts, modules.conf, etc.)  This is not a task for udev.
 
+Q: But I love that feature of devfs, please?
+A: The devfs approach caused a lot of spurious modprobe attempts as
+   programs probed to see if devices were present or not.  Every probe
+   attempt created a process to run modprobe, almost all of which were
+   spurious.
+
 Q: I really like the devfs naming scheme, will udev do that?
 A: Yes, udev can create /dev nodes using the devfs naming policy.  A
    configuration file needs to be created to map the kernel default names
-   to the devfs names.  See the initial udev.conf.devfs file in the udev
+   to the devfs names.  See the initial udev.rules.devfs file in the udev
    release.  It is the start of such a configuration file.  If there are
    any things missing, please let the udev authors know.
 
@@ -78,6 +84,33 @@ Q: How will udev handle devices found before init runs?
 A: udev will be placed in initramfs and run for every device that is found.
    Work to get this implemented is still underway.
 
+Q: Can I use udev to automount a USB device when I connect it?
+A: Technically, yes, but udev is not intended for this. Projects that do
+   automount hotplugged storage devices are:
+     * Usb-mount http://users.actrix.co.nz/michael/usbmount.html
+     * devlabel http://linux.dell.com/projects.shtml#devlabel   
+                                                             
+   Alternatively, it is easy to add the following to fstab:  
+   /udev/pendrive       /pendrive       vfat    user,noauto             0       0
+
+   This means that users can access the device with:
+   $ mount /pendrive
+   And don't have to be root but will get full permissions on /pendrive.
+   This works even without udev if /udev/pendrive is replaced by /dev/sda1
+
+Q: Are there any security issues that I should be aware of?
+A: When using dynamic device numbers, a given pair of major/minor numbers may
+   point to different hardware over time. If a user has permission to access a
+   specific device node directly and is able to create hard links to this node,
+   he or she can do so to create a copy of the device node. When the device is
+   unplugged and udev removes the device node, the user's copy remains.
+   If the device node is later recreated with different permissions the hard 
+   link can still be used to access the device using the old permissions.
+   (The same problem exists when using PAM to change permissions on login.)
+    
+   The simplest solution is to prevent the creation of hard links by putting
+   /dev in a separate filesystem (tmpfs, ramfs, ...).
+    
 Q: I have other questions about udev, where do I ask them?
 A: The linux-hotplug-devel mailing list is the proper place for it.  The
    address for it is linux-hotplug-devel@lists.sourceforge.net