bug#10311: RFE: Give chmod a "-h" option as well

[Bob Proulx]

severity 10311 wishlist
thanks

Jan Engelhardt wrote:
> Give chmod a "-h" option as well

There are several important points concerning symlinks, the mode bits,
chmod(1) and chmod(2).

* The mode bits of a symlink are not used.  The original Unix authors
  ignored them and did not provide any way to change them.

* The mode bits of a symlink are set when they are created and never
  modified nor used after that time.

* Some operating systems do allow symlink mode bits to be set but that
  feature is not wide spread.

Since the mode bits of a symlink are not in any way significant there
isn't any urgent need to change them.  The displayed value is
completely cosmetic and without function.  This is an FAQ.

  
http://www.gnu.org/software/coreutils/faq/#How-do-I-change-the-ownership-or-permissions-of-a-symlink_003f

> chown(1) has a -h option by which it affects symlinks directly rather

The chown(1) command can do this because the lchown(2) operating
system call exists which provides that functionality.  But there
isn't any equivalent lchmod(2) function call.  If an lchown(2) system
call were to exist then adding an option to chmod(1) would be possible.

I have always considered this inconsistent that lchown(2) exists
without lchmod(2) existing.  But I was not consulted in the
implementation.  Likewise creat(2) is missing the 'e'.  It is just the
way things are.  A small number of those inconsistencies must be
accepted after 40 years of use.

The ability to set the mode bits of a symlink have never been
implemented without the lchmod(2) system call because in order to
change the mode bits of a symlink it would be necessary to remove the
previous one and then create a new one with the desired mode bits by
specifying the umask at time of creation.  This would have other
serious negative side-effects not commensurate with the cosmetic value
of the display of the mode bits since the mode bits are never used.
The ownership and group would then be that of the creating process.
There would need to be special care taken such that at no time would
any other process find that the symlink had been removed during this
removal and creation process.

> Attempting chmod -R g+w /home/groups/evilgroup is still a risk, and
> would necessity a more long-winded command involving find(1). It
> would therefore be welcome that chmod receive an -h option that just
> skips over them (besides perhaps attempting to change their
> permissions as well).

I am sorry but I did not understand the problem you are describing in
this text.  Neither chmod -R nor find by default dereference symlinks.

Try using chmod's -v option to have it emit messages concerning
actions taken or actions not taken.  I think the output is useful.

Bob