Symbolic and Hard Links

Elvaen

Registered
Hey all

First off let me explain what I did. I created a symbolic link to my 2nd hard drive under "/" so I don't have to go through "/Volumes" to get there. Is there an easier way to do this? The GUI's "Computer" shows all the mounted volumes, I assume it does this by referencing the volumes folder when it creates the list?

Second, my question has to do with file permissions. For example, I want to completely cut off my other HD from any other user, save myself. I know how to do that by editing groups, etc. I'm curious as to how permissions work when related to symbolic links. Is the target checked for file permissions when a user attempts to follow a link?

Also though I've read some material on it, including the man pages I'm not really sure about the differences between a symbolic link and a hard link. Correct me where I'm wrong.

A symbolic link is like an alias, but unlike aliases in Mac OS 9 where you could have an alias to an application and then move that said application into another folder and still have a functioning alias, in OS X you can't do that. Symbolic links (aliases) are more or less just a file path and if the path is changed in anyway the link is broken. yes? So in that respect they work more like Window's target files... as soon as the file path changes the link is broken.

I don't know too much about hard link's except that they can't reference a directory and they don't break simply by changing the file path as a symbolic link does. I've read some material that says choosing between using a symbolic link and a hard link is often just a matter of taste. I find that hard to believe because the differences are non-trivial...  Under what situation would you want to use a hard link over a symbolic link?

Comments appreciated :)

-Elvaen
 
ln -s is typically preferred because it's easier to manage. If speed is a critical concern you can use hard links to avoid the additional name lookup.
if you have a hard link to something, you can't get rid of it as easily. A file space is only marked as free when there are no more references to it. So if you have something hard-linked and you get rid of the original, you also have to find the link and trash that before the file is really gone.

security should be retained either way, although not directly reflected on a symlink, it merely resolves to another file and that file's permissions are respected. When you change permissions on a hard link, they are properties of the file, and are refllected in all names that point to that file.

The security hole is this - some protection is offered by the pathname. If I state that no one can look inside of /var/cron/ except root, the permission of that folder is only checked if it is in the path. Linking hard makes a new path, symlinking reequests that the user take the original path.

because hard links stay on a logical volume, there shouldn't be any way to violate the permissions of an entire volume.

with regards to being like an alias, there is no real equivalent. hardlinks resolve link aliases in that they don't pay attention to the original's name. symlinks behave properly to deleted files in that they arent' the original, so throwing away the original really makes it go away.

currently the Finder will follow all of them, AppleShare will only follow aliases, but not outside of it's share folder, and command line will only follow links obeying the long standing Unix rules stated above. The finder also does something neat, it treats all links and aliases alike it seems, and it attempts to open the file according to all possible paths, and if you have one, it uses it. This means it should continue to track files despite name changes, but will honor permissions.
 
To restrict a volume to only 1 user, so you don't have to share your pr0n:

Terminal commands:

chown username /pr0ndrive
chmod 700 /pr0ndrive

Now it's all for you!
 
on my box I issued the commands

su (password)
chflags nouchg -r /Volumes/Pr0nDr1v3
chown -R theed /Volumes/Pr0nDr1v3
chmod -R go-rwx /Volumes/Pr0nDr1v3

but I guess if you already have that link from / it wouldn't make much difference. :)
 
Back
Top