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 [email protected] +1-919-301-3266 Libvirt virtualization library http://libvirt.org
signature.asc
Description: OpenPGP digital signature
