Oh, this is fun - not: apparently ln behaves quite differently on Linux and on MacOSX (using stock Darwin/ln or ln from GNU/coreutils):

$ uname -s && ln --version | head -1
Linux 2.6.33-rc1
ln (GNU coreutils) 6.10

$ umask 0022
$ mkdir test
$ umask 0066
$ ln -s test a

$ ls -ldog test a
lrwxrwxrwx 1    4 2009-12-25 13:01 a -> test
drwxr-xr-x 2 4096 2009-12-25 13:00 test

and on the Darwin side:

$ uname -sr
Darwin 10.2.0

$ umask 0022
$ mkdir test
$ umask 0066
$ ln -s test a

$ ls -ldog test a
lrwx--x--x  1    4 Dec 25 13:02 a -> test
drwxr-xr-x  2   68 Dec 25 13:02 test

$ /opt/local/bin/gln --version | head -1
ln (GNU coreutils) 7.6
$ /opt/local/bin/gln -s test b

$ ls -ldog b
lrwx--x--x  1   4 Dec 25 13:12 b -> test

So, who's right?

Grrr, s9y mag kein HTML in Kommentaren, dann muss ich das hier loswerden: Danke fuer das Feedback, gnarf, trotzdem ist das inkonsistent:

$ umask 0666
$ ln -s test a
$ touch b

$ ls -ldog test a b
ls: a: Permission denied
l--x--x--x  1    4 Dec 25 15:01 a
----------  1    0 Dec 25 15:01 b
drwxr-xr-x  2   68 Dec 25 14:58 test

$ rm a b
override ---------  christian/staff for b? y

....but rm doesn't ask for permission to remove "a". I'm looking up symlinks in die POSIX documents, but so far no word on messing around with umasks. And why should they, given that permission checks are done on the target anyway. When using creating a file in Linux, strace(1) shows:

  open("c", O_WRONLY|O_CREAT|O_NOCTTY|O_NONBLOCK|O_LARGEFILE, 0666) = 3

while creating a symlink simply does

  symlink("test", "b")                    = 0

And the symlink() part looks pretty much the same as the POSIX reference.