On Mon, Aug 24, 2009 at 8:08 AM, Edward Ned Harvey<sola...@nedharvey.com> wrote: >> >It's a strange question anyway - You want a single file to have >> permissions >> >(suppose 755) in one directory, and some different permissions >> (suppost 700) >> >in some other directory? Then some users could access the file if >> they use >> >path A, but would be denied access to the same file if they used path >> B? >> >That's weird. >> > >> >It makes no sense to attempt setting perms on a symlink. The perms >> are >> >determined by the actual file. The symlink is just another name for >> the >> >file itself. If you want to change perms of the file, change the >> perms of >> >the file. >> >> I think the purpose, at least for Solaris, would be making sure that >> chmod() doesn't follow symlinks. lchmod() used on a symbolic link >> would >> be a no-op. > > > My point exactly. I'm being bold or brazen or ignorant by saying: There is > no point to do a chmod and not follow symlink. Chmod should always follow > symlinks. That's why it's the default behavior, and that's why it's rare, > strange, or impossible to override that behavior.
No it shouldn't. Alice$ cd ~/proj1; ln -s /etc ., Alice$ echo "Hi helpdesk, Bob is on vacation and he has a bunch of files in my home directory for a project that we are working on together. Unfortunately, his umask was messed up and I can't modify the files in ~alice/proj1. Can you do a 'chmod -fR a+rw /home/alice/proj1' for me? Thanks!" | mailx -s "permissions fix" Helpdesk$ pfexec chmod -fR a+rw /home/alice/proj1 Alice$ rm /etc/shadow Alice$ cp myshadow /etc Alice$ su - root# -- Mike Gerdts http://mgerdts.blogspot.com/ _______________________________________________ zfs-discuss mailing list zfs-discuss@opensolaris.org http://mail.opensolaris.org/mailman/listinfo/zfs-discuss
