Correct for a hard link but not for a symbolic link. The content of a symbolic link is just a string. This allows a symbolic link to point to a filesystem that isn't currently mounted, for instance. A symbolic link is just text; when the kernel encounters one, it essentially inserts the symbolic link into the path that it was looking up, breaking it up into slash-delimited pieces and looking up
.. as appropriate. Symbolic links don't give extra permission: the traversals caused by the path elements that come from the symbolic link obey the same permission constraints as if the application had specified those path elements. A symbolic link has its own inode (or at least it appears this way — under the hood, some filesystems don't allow symlinks to have multiple hard links and store the symlinks directly in the directory that contains them, but it still reports an inode number to the
At the system level, how symbolic links are treated depends on the type of operation. Operations that act on directory entries (e.g. renaming, deleting) treat symbolic links like any other file. Operations that act on file contents (e.g.
chdir) follow the symbolic link and act on the target (and report an error if the symlink chain ends with a broken link). For operations that act on the file metadata (i.e. on the inode), it depends: for some operations, there's a pair of functions (e.g.
lstat), for others the symlink is followed (e.g.
utimes have no symlink variant on Linux).