Subject: bizarre symbolic link problem
To: None <current-users@NetBSD.ORG>
From: John F. Woods <jfw@jfwhome.funhouse.com>
List: current-users
Date: 10/18/1997 12:18:16
I have (courtesy of MH) a symbolic link named @ on one disk partition pointing
to a file in MH's mail inbox directory:

$ pwd
/mnt/new
$ ls -l @
lrw-r--r--  1 jfw  wheel  22 Oct 18 11:29 @ -> /u/jfw/Mail/inbox/8902
$ ls -ld /mnt
drwxr-xr-x  497 jfw  wheel  8704 Oct 14 19:39 /mnt
$ ls -ld /mnt/new
drwxr-xr-x  18 jfw  wheel  17408 Oct 18 11:29 /mnt/new
$ ls -l /u/jfw/Mail/inbox/8902
-rw-r--r--  1 jfw  staff  961 Oct 18 11:25 /u/jfw/Mail/inbox/8902

I cannot "cat" the symbolic link because I get "permission denied".

Hmm.  OK, I see the problem.  Symbolic links now need execute permission
to be useful, even when they point to a file and not to a directory.  MH was
written before symbolic links had useful permissions, and (apparently)
has managed to shut off execute permission on the symlink.  (I'm not sure
I see *how*, though, since it doesn't set the umask to 0033, and it doesn't
contain a call to lchmod().)

This change, though arguably sensible, has broken an old and perfectly
reasonable program.  I'd like to ask the the change be at least reconsidered,
since it is not without impact.  I'll look into MH to see how to fix it.

Something else that is definitely haywire:

$ ln -s /u/jfw/Mail/inbox/7777 @
$ ls -l @
lrwxr-xr-x  1 jfw  wheel  22 Oct 18 11:57 @ -> /u/jfw/Mail/inbox/7777
$ mv @ ~

OK.

$ rm ~/@
$ ln -s /u/jfw/Mail/inbox/7777 @ 
$ chmod -h 666 @
$ mv @ ~
mv: @: Permission denied

Since when does mv require execute permission to move a file???
(note: this is a cross-device "mv", so it's really a cp followed by
rm, as was recently beaten to death by, uh, someone.  :-)  I don't
think I see where this is happening, either; a really cursory glance
through the code indicates that readlink checks the read permission,
not execute.  (Unless namei() won't even touch a no-execute symlink?)

Ah.  mv does a stat() to find out what the from file is, and that is
failing.  It should probably do an lstat() since if it is moving a
symbolic link (which will work because cp is told not to follow them),
it is irrelevant what the modes on the target file are.  I'll send-pr
this so it doesn't get lost.