From 4723bf98c0835bc779f627d7125417aa4f84121d Mon Sep 17 00:00:00 2001 From: "Ballarin.Marc@gmx.de" Date: Tue, 10 Aug 2004 00:49:36 -0700 Subject: [PATCH] Update the FAQ with info about hardlink security --- FAQ | 15 ++++++++++++++- 1 file changed, 14 insertions(+), 1 deletion(-) diff --git a/FAQ b/FAQ index 28f7552ae3..45337bf635 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 @@ -98,6 +98,19 @@ A: Technically, yes, but udev is not intended for this. Projects that do 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 -- cgit v1.2.3-54-g00ecf