Symbolic links have evolved over the years. At first, a symbolic link was followed only when opening a file. So:
touch datafile
ln -s datafile slink
chmod 700 slink
did not protect the file called "datafile". This was a security problem. Today that "chmod 700 slink" will change the permissions on datafile. "chown fred datafile" will also change datafile and leave slink alone.

Symbolic Links Must have an Owner

There is a way to change the owner of a symbolic link. It is "chown -h slink". This will change slink and leave datafile alone. The original reason why symbolic links need an owner is a feature called "quotas". Quotas allows the system administration to limit the disk space used by a user. A symbolic link consumes a small amount of disk resources so it must be charged to the appropiate user. We now have a second reason: sticky directories. We need to know who can remove a symbolic link from a sticky directory.

In addition to an owner, Posix requires that symbolic link have a size. That is all that you can depend on. Symbolic links may not even have any permission bits.

Permission Bits Are Required by Posix to be Ignored

On Solaris and Linux, newly created symbolic links are 777 and this is not affected by umask. I could not not find any way to turn the bits off. On HP-UX, symbolic links are also created with 777, but umask does affect this. So:
umask 777
ln -s datafile slink
creates a symbolic link with all of the bits turns off. This had no effect at all on what I could do with datafile. And symbolic link (with a mode of 0) to directories also worked fine.

BSD Has a Way to Change the Permission Bits on a Symbolic Link

The various BSD distros all have a "chmod -h" which is like the required "chown -h". Using this command I tested symbolic links on FreeBSD and found that they ignore permission bits as well. The "chmod -h" command is implemented using a lchmod() system call. (BSD even has a lutimes() system call and a "touch -h" command to invoke it.) So far, so good. Nothing here is violating the Posix standard.

NetBSD May be Violating the Posix Standard

According to the NetBSD symlink man page: "The readlink(2) system call requires read permissions on the symbolic link." readlink() is the system call used by ls to display the target of a symbolic link. So with something like this: that datafile was obtained with readlink(). I don't have access to a NetBSD system for testing so I could not verify this.

HP-UX Transition Links

When HP rewrote HP-UX to conform to System V Release 4, the location of lots of files changed. As one example, my favorite shell moved from /bin/ksh to /usr/bin/ksh. Some people still use /bin/ksh and that will work (for now) because of a symbolic link:
How is HP turning on that sticky bit? The lchmod() system call has been borrowed from BSD. This is an undocumented feature of HP-UX. HP's idea is that they can be sure that a sticky symlink was not created by any users because users do not know about lchmod. Using lchmod() to turn on the sticky bit does not change the properties of the symlink in any way. The only difference is that HP's tl tools will be willing to operate on the symlink.

But here is what the HP-UX faq has to say: "Transition links are a bit faster, because the linked-to filename is stored in the inode itself, instead of using an allocation unit to store the link." While that statement is not exactly false, it is terribly misleading. HP-UX simply supports fast symlinks. If the referenced file name is short enough, it is stored directly in the inode. The transition links happen to be short enough. I have seen some people use lchmod() to turn on the sticky bit of a symlink in an effort to speed things up. It does not work like that.

Transition links are starting to disappear. People who have not switched from /bin/ksh to /usr/bin/ksh may one day get a rude surprise. Below are some links to HP's website.

Maintaining Transition Links
Transition Links Commands (Deprecated)
Transition Links (Deprecated)