On 7/2/06, Joerg Schilling <[EMAIL PROTECTED]> wrote:
[EMAIL PROTECTED] wrote:
>
> >1) Is there a reason that lchmod() doesn't already exist that is
> >deeper than "no one has had time"?
>
> Perhaps because you can't chmod symlinks? There no reason why it
> can't exist.
POSIX allows symlinks to avoid file meta data (i.e. inodes).
Solaris implements inodes for symlinks but ignores owner and permissions.
Perhaps I lost sight of my original goal. Since the permissions on a
symlink really don't matter, perhaps the a -h option on chmod(1)
doesn't really need to alter a symlink. Ignoring it may be
sufficient. I'm now thinking that the best fix for 4786969 be to just
lstat(3C) before chmod(2) and ignore those that are symbolic links.
Why does this matter? I have had many times in my life as a sysadmin
where files or directories owned by root got their permissions
changed. In a number of cases, I checked the helpdesk ticket log and
found that there were cases along the lines of "Fred no longer works
here. Please change the ownership of all files in ~fred/project to be
rw by group freds-old-team and no one else." The action taken by the
junior admin is "chgrp -Rh freds-old-team ~fred/project; chmod -R
g+rw,o-rwx ~fred/project". How much damage is done if fred has the
symbolic links to /etc, /net/server/something, and
/projects/some-other-projects?
The best work around for this is to use some incarnation of find that
is either very inefficient (find -exec) or is going to choke when it
runs across some files (find | xargs chmod, "New Document (2).doc").
chmod -Rh is easier to grok than "find $dir - type -l -o ..."
Mike
--
Mike Gerdts
http://mgerdts.blogspot.com/
_______________________________________________
opensolaris-code mailing list
[email protected]
http://mail.opensolaris.org/mailman/listinfo/opensolaris-code
