Rick Green
From your explanation, it would appear that in the case of a hard link, the ownership/permissions of whatever name was referenced would be the only one controlling the access, since the other directory entry wouldn't even get read. Am I right so far?
Keep in mind that access is not granted according to the file's permissions (stored in the inode) only. Permissions of all directories in the file's full path are taken into account too. (So the answer to your question is no.)
But in the case of 'soft' or symbolic links, the link is a reference to the primary file name, so both directory entries get read when a reference is attempted thru the link. Which directory entry's ownership/permissions will control the access?
The target permissions are important, permissions of symbolic links are not used!
My specific question dealt with symbolic links to device files, specifically /dev/cdrom -> /dev/scd0 and /dev/cdrecorder -> /dev/scd1.
Use the -L option of "ls" to dereference symbolic links: $ ls -l /dev/cdrecorder lrwxrwxrwx 1 root root 4 Jun 30 21:47 /dev/cdrecorder -> scd0 $ ls -lL /dev/cdrecorder brw------- 1 malusek malusek 11, 0 Sep 24 03:54 /dev/cdrecorder
Also links to executables with suid/sgid bits set.
The situation is the same as for other permissions. -- Alexandr.Malusek@imv.liu.se
Thank you for the explanation. That helps a lot. I guess I need to do some reading on the internal structure of ext2. This statement confused me: On 28 Dec 2001, Alexandr Malusek wrote:
Keep in mind that access is not granted according to the file's permissions (stored in the inode) only. Permissions of all directories in the file's full path are taken into account too. (So the answer to your question is no.)
I was thinking that the 'inode' was roughly equivalent to the 'FAT' in the dos world, and contained nothing more than a pointer to a physical cluster(s). So the directory contains a name and owner, pointing to an inode, which contains permissions, and points to a physical sector? I thought inodes were more or less tied to a physical cluster, kinda like the FAT If the permissions of the parent directories are important, then it seems the access to a linked file is much more complicated than necessary. A hard link points directly to an inode, which may be in a much different part of the filesystem tree (although on the same partition). So if I'm accessing /home/rtg/bin/foo which is a link to /usr/X11/bin/bar, I chase the filesystem down the directory path to /home/rtg/bin/foo, then get a pointer to inode 12345. At this point, how am I supposed to find out what the 'real' parent directories of this file are? Does the inode also contain reverse or upward pointers to its parents? Even in the case of a symbolic link, where you will be chasing the filesystem down the full path to the target, it seems like a lot of IO to have to read every directory and it's inode in the path, just to find out if its permissible to read the data. I'm amazed that these systems manage to perform as well as they do! -- Rick Green "They that can give up essential liberty to obtain a little temporary safety, deserve neither liberty nor safety." -Benjamin Franklin
On Friday 28 December 2001 22.16, Rick Green wrote:
Thank you for the explanation. That helps a lot.
I guess I need to do some reading on the internal structure of ext2. This statement confused me:
On 28 Dec 2001, Alexandr Malusek wrote:
Keep in mind that access is not granted according to the file's permissions (stored in the inode) only. Permissions of all directories in the file's full path are taken into account too. (So the answer to your question is no.)
I was thinking that the 'inode' was roughly equivalent to the 'FAT' in the dos world, and contained nothing more than a pointer to a physical cluster(s). So the directory contains a name and owner, pointing to an inode, which contains permissions, and points to a physical sector? I thought inodes were more or less tied to a physical cluster, kinda like the FAT If the permissions of the parent directories are important, then it seems the access to a linked file is much more complicated than necessary. A hard link points directly to an inode, which may be in a much different part of the filesystem tree (although on the same partition).
An inode isn't in the filesystem tree. An inode is on a partition, and has one or more hardlinks pointing at it in the filesystem tree. Ownership and permissions are in the inode only.
So if I'm accessing /home/rtg/bin/foo which is a link to /usr/X11/bin/bar, I chase the filesystem down the directory path to /home/rtg/bin/foo, then get a pointer to inode 12345. At this point, how am I supposed to find out what the 'real' parent directories of this file are? Does the inode also contain reverse or upward pointers to its parents?
There is no 'real' parent. There is absolutely no difference between two hardlinks, in the sense that there is no 'real' and 'false' link. Both are links to an inode, that is all. regards Anders
participants (3)
-
Alexandr Malusek -
Anders Johansson -
Rick Green