On Fri, 2007-01-12 at 08:44 -0500, Mitchell Laks wrote: > Hi, > > I have noticed that a number of the video programs xine ogle etc > like to use > /dev/dvd as a default > > However they seem to also want the group permission to be > cdrom... > > > Note when i do > ls -l /dev/hdc > brwsrwxrwx 1 root cdrom 22, 0 2007-01-09 10:08 /dev/hdc > > however when I do as root > ln -s /dev/hdc /dev/dvd > > then i get > ls -l /dev/dvd > lrwxrwxrwx 1 root root 3 2007-01-09 10:08 /dev/dvd -> hdc > > when i do > chmod root:cdrom /dev/dvd > > i still get > > ls -l /dev/dvd > lrwxrwxrwx 1 root root 3 2007-01-09 10:08 /dev/dvd -> hdc Symbolic links are by design that way, they are symbols only. The permissions of the target are what matter. If something is complaining, then it should be noted that a bug should be filed as that is the improper handling. Please note that symbolic links only store the "name/path" to the target, being only a container for that info only and being readable by all accounts/groups/other. All other info is read from the actual target. Example follows: -rw-r----- 1 greg staff 1940 2006-11-02 14:50 stuff.log lrwxrwxrwx 1 greg greg 9 2007-01-12 11:59 stuff.that.I.really.need.to.look.at.txt -> stuff.log lrwxrwxrwx 1 greg greg 9 2007-01-12 11:58 stuff.tx1 -> stuff.log lrwxrwxrwx 1 greg greg 9 2007-01-12 11:53 stuff.txt -> stuff.log Just to tell you, the only ones able to read ANY of these files is: me and any accounts in the "staff" group regardless of the symbolic link. The link allows others to read the perms and that only. They are disbarred from reading the actual file. You'll also note they are an actual file with the info in them. Now look at a NON-symbolic link or hard link (which cannot be done across filesystems) -rw-r--r-- 2 greg greg 1940 2006-11-02 14:50 stuff.log -rw-r--r-- 2 greg greg 1940 2006-11-02 14:50 stuff.that.suck.txt Hard links are just that. Typically hard links are used for command that have the same executable, but react and do stuff differently when call from a different name. Hard links are not good to be used for "target name re-direction" as un-predictable things can and do happen and should never be used (especially in /dev) In any case, if you are using any kind of Debian Linux other than Woody or before, /dev is managed and should not be messed with directly. Rules for device file creation need to be made. /etc/udev is where this magic resides. For info on how-to do that go here: http://www.reactivated.net/writing_udev_rules.html Here ends the lesson on symbolic links, udev and the /dev no-nos Hope this helps. -- greg, greg@gregfolkert.net The technology that is Stronger, better, faster: Linux
Attachment:
signature.asc
Description: This is a digitally signed message part