In a word, no.
The kernel just uses the symlink to find the file/directory that the link points to.
Take the example
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.