Are world-readable/writable/executable links in /usr/bin security holes?

From the Wikipedia entry for Symbolic link:

The file system permissions of a symbolic link usually have relevance only to rename or removal operations of the link itself, not to the access modes of the target file which are controlled by the target file's own permissions.

Because that symlink is owned by root, only he can change it. E.g.

# ln -s /bin/ls blah
# ls -la blah
lrwxrwxrwx 1 root root 7 Fev 28 15:07 blah -> /bin/ls
$ rm blah
rm: cannot remove `blah': Operation not permitted
$ ln -s blah /bin/true
ln: failed to create symbolic link `/bin/true': File exists

In a word, no.

The kernel just uses the symlink to find the file/directory that the link points to.

Take the example view => vim (a common symlink in /usr/bin, call vim by the name view and it will open the text file read only).

The kernel will 'open' view, see it is a pointer to vim, close view and then open vim. As it opens/exec's vim, it uses all the security checks on vim. So vim is still opened with the permissions on vim, which is what you expect.

Ah ha! But a symlink iss a file, and if it's writeable, I can open it, edit it, and change the target! /usr/bin/view becomes a pointer to /tmp/myevilexec. In a word, no. It's a special file, you can not open the symlink 'file' and edit it this way. You can only replace the symlink, and then the perms on the symlink are irrelevant - directory perms determine whether you can delete files/create new files.

In short, 777 for symlinks is not a security hole, and it makes perms of the symlink 'invisible' and perms in effect are the target file, which is what you expect.

answering own question after figuring it out:

I have figured this out. This would be a security hole, except for the fact that /usr/bin is owned by root and not world-writable, and thus you cannot modify the link. If /usr/bin was world-writable, you could replace the link with your own link, but that is not the case.

As a proof of concept:

% cd
% sudo touch rootfile
% sudo ln -s rootfile rootfile_link
% touch evilfile
% ln -s evilfile evilfile_link

# works, but only if directory permissions are correct:
% cp evilfile_link rootfile_link

However if there was a way to edit the actual symlink file (it's just a short snippet of text I think), it would be possible to be evil.

Thus I will actually hold off on accepting any answer until someone can come up with strong evidence that a symlink can/can't be modified, or replaced-with-permissions-intact, and accept that answer.