On Aug 24, 2009, at 8:32 AM, Mike Gerdts wrote:

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"

Yeah, but that is just a social engineering attack.
If you change chmod, you can just change the suggested
command, and achieve similar results. cp and rm are favorite
targets, too.  IMHO, the real problem here is that there is a
multitude of cp, rm, chmod, ls, and other commands or shell
builtins -- most folks won't know which one they are currently using :-(
 -- richard


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

_______________________________________________
zfs-discuss mailing list
zfs-discuss@opensolaris.org
http://mail.opensolaris.org/mailman/listinfo/zfs-discuss

Reply via email to