GNU bug report logs - #79130
Change/feature requests chcon/chgrp/chmod/chown/touch

Previous Next

Full log

View this message in rfc822 format

From: Pádraig Brady <P <at> draigBrady.com>
To: Martin D Kealey <martin <at> kurahaupo.gen.nz>, 79130 <at> debbugs.gnu.org
Subject: bug#79130: Change/feature requests chcon/chgrp/chmod/chown/touch
Date: Thu, 31 Jul 2025 11:49:16 +0100

On 30/07/2025 22:51, Pádraig Brady wrote:
> On 30/07/2025 09:05, Martin D Kealey wrote:
>> I would like the 'chown -h' and 'chcon -h' to work the same way as
>> 'touch -h': as well as not following symlinks for targets, they should also
>> not follow a symlink given as --reference=.
> 
> For consistency it probably makes sense for `chmod -h` to also
> not follow a symlink given as --reference=.
> I know mode bits are less supported on symlinks on various systems,
> but for consistency it probably makes sense.
> Note -h, -HLP was added to chmod(1) only recently:
> https://github.com/coreutils/coreutils/commit/07a69fc3b
> I just didn't consider --reference behavior when implementing that.
> 
> 
>> I know these would be incompatible changes, but to me this would seem more
>> obvious, useful and consistent. What was the rationale for the existing
>> behaviour, given that the POSIX specs for these commands lack any
>> discussion of symlinks (and mostly they lack '-h' entirely)?
> 
> POSIX ch{own,mod}(1) also lack --reference, so we're more flexible in how
> we treat these GNU extensions. As for why these always deref --reference I don't know.
> For chown(1), --reference did come after -h, so I suspect it was just not considered.
> Then chcon(1) and chmod(1) just copied what chown(1) was doing.

Thinking a bit more about compatibility, given the existing behavior
has been in place so long, and you'd usually want to read metadata
from the --reference target (especially for chmod),
I'm now a bit reluctant to change -h for chmod, chown, and chcon.

Also --reference is a one to many metadata copy operation,
so you may want/prefer to treat source and dest differently.

Also -h is mainly a security feature when _writing_ the new metadata,

But we could make it more explicit and easy to achieve the functionality
by extending the long option form of -h. I.e. support:
  --no-dereference={source,dest(default),all}

touch(1) would remain:
  --no-dereference={source,dest,all(default)}

If implementing now, I'd have all commands consistent with touch(1),
but with the current situation it would be safer to proceed as above.

I'm happy to implement that above scheme,
which is trivial enough to do.

cheers,
Padraig

Previous Next

GNU bug tracking system
Copyright (C) 1999 Darren O. Benham, 1997,2003 nCipher Corporation Ltd, 1994-97 Ian Jackson.