In addition to all other answers I want to point out the following important properties:
A softlink is a true reference, i.e. it is a small file that contains a pathname. Resolving a softlink happens transparently to the application: if a process opens a file, say
/this/path/here which is a symlink pointing to
/that/other/path then the entire handling of opening
/that/other/path is done by the OS. Furthermore, if
/that/other/path happens to be a symlink itself, then this is also being dealt with by the OS. In fact, the OS follows the chain of symlinks until it finds something else (e.g. a regular file) or until it reaches
sysconf(3)) many entries, in which case the OS (more precisely: the according system call) returns an error and sets
ELOOP. Thus, a circular reference like
xyz -> xyz will not stall the process. (For Linux systems see
path_resolution(7) for full details.)
Note that a process can check whether a pathname is a symlink or not through the use of
lstat(2) and may modify its file attributes (stored in the inode table) through
lchown(2) and others (see
symlink(7) for the whole story.)
Now, in terms of permission you will notice that symlinks always have permissions 777 (
rwxrwxrwx in symbolic notation). This is the due to the fact that any other permissions can be bypassed by accessing the actual file, anyway. Conversely, 777 for a symlink does not make the symlinked file accessible if it was not accessible in the first place. For instance, a symlink with permissions 777 pointing to a file with permissions 640 does the file not make accessible for "other" (the general public). In other words, a file
xyz is accessible through a symlink if and only if it is directly accessible, i.e. without indirection. Thus, the symlink's permissions have no security effect whatsoever.
One of the main visible differences between hardlinks and symlinks (a.k.a. softlinks) is that symlinks work across filesystems while hardlinks are confined to one filesystem. That is, a file on partition A can be symlinked to from partition B, but it cannot be hardlinked from there. This is clear from the fact that a hardlink is actually an entry in a directory, which consists of a file name and an inode number, and that inode numbers are unique only per file system.
The term hardlink is actually somewhat misleading. While for symlinks source and destination are clearly distinguishable (the symlink has its own entry in the inode table), this is not true for hardlinks. If you create a hardlink for a file, the original entry and the hardlink are indistinguishable in terms of what was there first. (Since they refer to the same inode, they share their file attributes such as owner, permissions, timestamps etc.) This leads to the statement that every directory entry is actually a hardlink, and that hardlinking a file just means to create a second (or third, or fourth...) hardlink. In fact, each inode stores a counter for the number of hardlinks to that inode.
Finally, note that ordinary users may not hardlink directories. This is because this must be done with utmost caution: an unwary user may introduce cycles into the otherwise strictly hierarchical file tree, which all usual tools (like
fsck) and the OS itself are not prepared to deal with.