bug#10311: RFE: Give chmod a "-h" option as well

[Eric Blake]

On 12/16/2011 12:04 PM, Eric Blake wrote:
>> It would be informative to myself and I expect others if you could
>> post an example of the behavior from a BSD system showing the
>> restriction through a symlink's permissions.
> 
> But I still remember reading about permissions affecting symlinks on at
> least one BSD variant (I'm still trying to find where I remember that
> from); something like 'w' permissions were required for readlink(2) to
> succeed, and 'x' permissions required for open(2) and friends to
> successfully follow the symlink.  I'll post back if I can find more
> evidence.

NetBSD is the one I was remembering, and it is a per-device mount-option
that controls whether permissions matter (alas, I have no root
permissions on any of the NetBSD systems I currently have access to, in
order to try out the mount option and show an actual transcript of a
permission-enforced failure):

http://www.daemon-systems.org/man/symlink.7.html

     If the filesystem is mounted with the symperm mount(8) option, the sym-
     bolic link file permission bits have the following effects:

     The readlink(2) system call requires read permissions on the symbolic
     link.

     System calls that follow symbolic links will fail without
execute/search
     permissions on all the symbolic links followed.

     The write, sticky, set-user-ID-on-execution and
set-group-ID-on-execution
     symbolic link mode bits have no effect on any system calls (including
     execve(2)).

So it was 'r' and 'x' bits that matter ('w' is still inconsequential,
even with symperm enabled on a device, although lchmod() and
fchmodat(AT_SYMLINK_NOFOLLOW) let you modify all the bits).

-- 
Eric Blake   address@hidden    +1-919-301-3266
Libvirt virtualization library http://libvirt.org

signature.asc
Description: OpenPGP digital signature