David T-G wrote:
> MMC --
>
> % [root@qqs alternatives]# chmod g-w *77
> % [root@qqs alternatives]# ll *77
> % lrwxrwxrwx 1 root root 16 Jan 21 15:48 f77 -> /usr/bin/g77-3.2*
> % lrwxr-xr-x 1 root root 16 Dec 20 09:27 g77 -> /usr/bin/g77-3.2*
>
> This is expected. chmod doesn't work on links; you must chmod the target
> of the link. In other words, you cannot make a link that some can use
> and another link that some can't if they both point to the same file.
Correct. The user, group and mode of a symbolic link have no effect.
They are merely cosmetic. They in no way affect the security
permissions of the file to which the symlink points. If they did then
it would be possible for a non-root user to make a symlink to
/etc/passwd and gain root permission. But that can't happen because
permission, user, and group of a symlink have no effect.
The chmod command you ran actually affected the target of the symlink.
It is the permissions on the actual file being pointed to which are
interesting. If you looked there you would see that you changed the
underlying file.
On some systems it is possible to affect the useless mode of a
symlink. If so then chmod exposes this useless capability to the
command line. The pertinent information is this.
-h, --no-dereference
affect symbolic links instead of any referenced
file (available only on systems that can change the
ownership of a symlink)
Bob
_______________________________________________
Bug-fileutils mailing list
[EMAIL PROTECTED]
http://mail.gnu.org/mailman/listinfo/bug-fileutils
