Re: cant set group owner cdrom for link /dev/dvd



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@xxxxxxxxxxxxxxx

The technology that is
Stronger, better, faster: Linux

Attachment: signature.asc
Description: This is a digitally signed message part



Relevant Pages

  • Re: makefile with "ln"
    ... John Small wrote: ... And 'ln TARGET' form is not supported on OS/2, ... determines that hard links do not work but symbolic links do. ...
    (comp.os.os2.programmer.porting)
  • Re: [opensuse] Another back-up question - Over & over again
    ... On Monday 30 April 2007 11:13, Carlos E. R. wrote: ... It's important to distinguish hard links from symbolic links. ... Hard links are fundamentally restricted from ever crossing file system / ...
    (SuSE)
  • Re: Batch replacing files
    ... Please explain why an alias would not be relevant. ... Functionally a hard and symbolic links look the same to access the file. ... A hard link is a directory entry that points to the actual file (aka: ... Any other hard links to the same file remain valid because ...
    (comp.sys.mac.system)
  • Re: cp and symbolic links
    ... rsync uses hard links, not symbolic links. ... than useless since it makes you think you have a backup and you do not ... This will preserve the hard links. ...
    (uk.comp.os.linux)
  • Re: [Bulk] Re: Backup with rsync problem
    ... create a link to TARGET with the name LINK_NAME. ... hard links by default, symbolic links with --symbolic. ... and another reason to save rsync output. ... was working (i.e included dot files) not just the regular file part. ...
    (Fedora)