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

Previous Next

To reply to this bug, email your comments to 79130 AT debbugs.gnu.org.

Toggle the display of automated, internal messages from the tracker.

Message #5 received at submit <at> debbugs.gnu.org (full text, mbox):

From: Martin D Kealey <martin <at> kurahaupo.gen.nz>
To: bug-coreutils <at> gnu.org
Subject: Change/feature requests chcon/chgrp/chmod/chown/touch
Date: Wed, 30 Jul 2025 18:05:55 +1000

[Message part 1 (text/plain, inline)]

I searched the archives and it appears there was a related discussion in
bug#61720 <https://debbugs.gnu.org/cgi/bugreport.cgi?bug=61720>, but that
focused on aligning the documentation with the behaviour rather than the
other way around.

I've been using touch+chown+chmod+chcon with the --reference= option to
restore the metadata of a file that's had trivial (semantically
insignificant) changes done to it.

This works *except* when the file in question is a symbolic link: this
method does not reliably restore ownership, because 'chown -h
--reference=ORIGINAL REPLACEMENT' doesn't actually look at the original
symlink, it looks at the file it points at, or completely fails if that is
inaccessible or nonexistent.

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=.

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)?

An alternative (or additional) approach would be to add new explicit
options (such as '--symlink-reference' and '--follow-reference') to all of
the inode metadata manipulation commands including 'chcon', 'chgrp',
'chmod', 'chown', & 'touch'.

I'm willing to provide patches for either or both of these approaches.
(Whatever changes are made to 'chown', the corresponding changes would be
made to 'chgrp'.)

Stepping back, I'm wondered about regularising the options available to all
the file manipulation commands, so 'touch' would gain '-R', '-H', '-L', &
'-P', and 'chmod' would gain '-h', '-H', '-L', & '-P' (functionality
subject to whether the underlying FS supports
fchmodat(..., AT_SYMLINK_NOFOLLOW) aka lchmod), plus the corresponding long
options.

I hesitate to volunteer to implement 'touch --recurse' but if there's
enough enthusiasm I'll certainly look at it.

Although it's out of scope for this mailing list, it would be ideal if
these could be coordinated with the maintainers of 'chattr' (Linux
'e2fsprogs' package) and 'setfacl' (Linux 'acl' package).

Secondly, I note that 'touch -r' copies the atime and mtime separately; it
would be nice to be able to have --atime= and --mtime= as separate options,
as an alternative to both combined as --time=.
Again, I can provide a patch if this would be acceptable.

-Martin

[Message part 2 (text/html, inline)]

Message #8 received at 79130 <at> debbugs.gnu.org (full text, mbox):

From: Paul Eggert <eggert <at> cs.ucla.edu>
To: Martin D Kealey <martin <at> kurahaupo.gen.nz>
Cc: 79130 <at> debbugs.gnu.org
Subject: Re: bug#79130: Change/feature requests chcon/chgrp/chmod/chown/touch
Date: Wed, 30 Jul 2025 13:16:40 -0700

On 2025-07-30 01: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=.

Makes sense to me. Let's see what others think.

If the patch is nontrivial would you be OK with assigning copyright as 
per the usual GNU style? If so, I can send you the form for the paperwork.

Message #11 received at 79130 <at> debbugs.gnu.org (full text, mbox):

From: Pádraig Brady <P <at> draigBrady.com>
To: Martin D Kealey <martin <at> kurahaupo.gen.nz>, 79130 <at> debbugs.gnu.org
Subject: Re: bug#79130: Change/feature requests chcon/chgrp/chmod/chown/touch
Date: Wed, 30 Jul 2025 22:51:14 +0100

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.

> An alternative (or additional) approach would be to add new explicit
> options (such as '--symlink-reference' and '--follow-reference') to all of
> the inode metadata manipulation commands including 'chcon', 'chgrp',
> 'chmod', 'chown', & 'touch'.

That would only be needed if mixing metadata between symlinks
and non symlinks, which I don't see as that useful.

> 
> I'm willing to provide patches for either or both of these approaches.
> (Whatever changes are made to 'chown', the corresponding changes would be
> made to 'chgrp'.)
> 
> Stepping back, I'm wondered about regularising the options available to all
> the file manipulation commands, so 'touch' would gain '-R', '-H', '-L', &
> '-P', and 'chmod' would gain '-h', '-H', '-L', & '-P' (functionality
> subject to whether the underlying FS supports
> fchmodat(..., AT_SYMLINK_NOFOLLOW) aka lchmod), plus the corresponding long
> options.

chmod(1) got those options in coreutils 9.5 as mentioned above.
That was because it already had the -R option.
It's best to avoid adding -R functionality to commands in general, so I'd leave touch as is
> Secondly, I note that 'touch -r' copies the atime and mtime separately; it
> would be nice to be able to have --atime= and --mtime= as separate options,
> as an alternative to both combined as --time=.
> Again, I can provide a patch if this would be acceptable.

I don't understand this request.
Is it just an interface change to existing functionality?
If so that wouldn't be warranted IMHO.

thanks,
Padraig.

Message #14 received at 79130 <at> debbugs.gnu.org (full text, mbox):

From: Pádraig Brady <P <at> draigBrady.com>
To: Martin D Kealey <martin <at> kurahaupo.gen.nz>, 79130 <at> debbugs.gnu.org
Subject: Re: 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

Message #17 received at 79130 <at> debbugs.gnu.org (full text, mbox):

From: Martin D Kealey <martin <at> kurahaupo.gen.nz>
To: P <at> draigbrady.com
Cc: 79130 <at> debbugs.gnu.org, Martin D Kealey <martin <at> kurahaupo.gen.nz>
Subject: Re: bug#79130: Change/feature requests chcon/chgrp/chmod/chown/touch
Date: Sat, 2 Aug 2025 19:43:41 +1000

[Message part 1 (text/plain, inline)]

On Thu, 31 Jul 2025 at 07:51, Pádraig Brady <P <at> draigbrady.com> wrote:

> 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.
>
[and I wrote]

> > (functionality subject to whether the underlying FS supports
> fchmodat(..., AT_SYMLINK_NOFOLLOW) aka lchmod),
>

Funny you should mention that; it's already in my patch set (wrapped in
#ifdef CAN_CHMOD_SYMLINK).

> An alternative (or additional) approach would be to add new explicit
> > options (such as '--symlink-reference' and '--follow-reference') to all
> of
> > the inode metadata manipulation commands including 'chcon', 'chgrp',
> > 'chmod', 'chown', & 'touch'.
>
> That would only be needed if mixing metadata between symlinks and non
> symlinks, which I don't see as that useful.
>

I don't mean that those options would *only* take symlinks, rather that
they would be guaranteed to follow or not follow one if it happened to be
provided.

On the whole I prefer the suggestion to have
--no-dereference=[none|src|dest|all] except for the unnecessary negative.
I suggest «--derefence=[n[one]|s[rc]|d[est]|a[ll]]» and the corresponding
version «-D[n|s|d|a]», with --no-dereference being a synonym for
«--dereference=none»/«-Dn» or «--dereference=src»/«-Ds» whichever matches
«-h» behaviour in each command.

(I'll grant that «-D*mode*» is a bit clunky, but it avoids a profusion of
new single-letter options, and I've often wished that cp, mv, ln, etc had
«-B*mode*» (corresponding to «--backup=*mode*», rather than just «-b».)

> Stepping back, I'm wondered about regularising the options available to
> all
> > the file manipulation commands, so 'touch' would gain '-R', '-H', '-L', &
> > '-P', and 'chmod' would gain '-h', '-H', '-L', & '-P' (functionality
> > subject to whether the underlying FS supports
> > fchmodat(..., AT_SYMLINK_NOFOLLOW) aka lchmod), plus the corresponding
> long
> > options.
>
> chmod(1) got those options in coreutils 9.5 as mentioned above.
> That was because it already had the -R option.
>

Oh, I was looking at v9.1, since that's what was shipping with Debian 12.11
(stable) released 2 months ago.
I should have looked at the newer git branches in Savannah, sorry.

It's best to avoid adding -R functionality to commands in general, so I'd
> leave touch as is
>

Fair point.

I had also been pondering adding --ref-prefix= where each target file would
obtain its reference from the corresponding file in another tree, which
would only really be useful with --recurse. (Doing that with internal
recursion would be a *lot* faster than, say «find . -type f -exec touch -h
--ref=/other/path/{} {} \;» since that needs a separate invocation of
«touch» for every target file.

In the same bucket of regularisation: every inode metadata command uses
«-c» to mean "verbose but only if it changes", EXCEPT «touch», where it's
"don't create". I don't suppose we could have a uniform
«--verbose=ifchanged»?

> Secondly, I note that 'touch -r' copies the atime and mtime separately;
> it would be nice to be able to have --atime= and --mtime= as separate
> options, as an alternative to both combined as --time=.
> > Again, I can provide a patch if this would be acceptable.
>
> I don't understand this request.
>

Currently it takes two invocations of ‘touch’ to change the atime and mtime
to different values, UNLESS you're using -r in which case just one
invocation will suffice: touch -r copies the reference's mtime onto the
target's mtime, and the reference's atime onto the target's atime.

The idea would be to be able to perform this using explicit values for
atime and mtime separately rather than using a reference file.


> Is it just an interface change to existing functionality?
>

Not really.


> If so that wouldn't be warranted IMHO.
>

Does my explanation make more sense?

-Martin

[Message part 2 (text/html, inline)]

Message #20 received at 79130 <at> debbugs.gnu.org (full text, mbox):

From: Pádraig Brady <P <at> draigBrady.com>
To: Martin D Kealey <martin <at> kurahaupo.gen.nz>
Cc: 79130 <at> debbugs.gnu.org
Subject: Re: bug#79130: Change/feature requests chcon/chgrp/chmod/chown/touch
Date: Sat, 2 Aug 2025 14:06:21 +0100

On 02/08/2025 10:43, Martin D Kealey wrote:
> On Thu, 31 Jul 2025 at 07:51, Pádraig Brady <P <at> draigbrady.com> wrote:
> 
>> 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.
>>
> [and I wrote]
> 
>>> (functionality subject to whether the underlying FS supports
>> fchmodat(..., AT_SYMLINK_NOFOLLOW) aka lchmod),
>>
> 
> Funny you should mention that; it's already in my patch set (wrapped in
> #ifdef CAN_CHMOD_SYMLINK).

It would be best to not vary the user interface defaults
based on system features.But yes, it would be good to keep ch{mod,own,con} interfaces in sync.

>> An alternative (or additional) approach would be to add new explicit
>>> options (such as '--symlink-reference' and '--follow-reference') to all
>> of
>>> the inode metadata manipulation commands including 'chcon', 'chgrp',
>>> 'chmod', 'chown', & 'touch'.
>>
>> That would only be needed if mixing metadata between symlinks and non
>> symlinks, which I don't see as that useful.
>>
> 
> I don't mean that those options would *only* take symlinks, rather that
> they would be guaranteed to follow or not follow one if it happened to be
> provided.
> 
> On the whole I prefer the suggestion to have
> --no-dereference=[none|src|dest|all] except for the unnecessary negative.
> I suggest «--derefence=[n[one]|s[rc]|d[est]|a[ll]]»

I agree --dererence=... would be best if implementing from scratch.
But given the existing --no-dereference, I would just extend that.

> and the corresponding
> version «-D[n|s|d|a]», with --no-dereference being a synonym for
> «--dereference=none»/«-Dn» or «--dereference=src»/«-Ds» whichever matches
> «-h» behaviour in each command.
> 
> (I'll grant that «-D*mode*» is a bit clunky, but it avoids a profusion of
> new single-letter options, and I've often wished that cp, mv, ln, etc had
> «-B*mode*» (corresponding to «--backup=*mode*», rather than just «-b».)

Interesting interface, but again I'm not sure another short option is warranted here,
especially a short option taking an argument.

> I had also been pondering adding --ref-prefix= where each target file would
> obtain its reference from the corresponding file in another tree, which
> would only really be useful with --recurse. (Doing that with internal
> recursion would be a *lot* faster than, say «find . -type f -exec touch -h
> --ref=/other/path/{} {} \;» since that needs a separate invocation of
> «touch» for every target file.

Interesting. Though if only a performance benefit
as opposed to functionality benefit, it's less warranted.

That reminds me of the --pairs0-from suggestion at:
https://lists.gnu.org/archive/html/coreutils/2024-08/msg00019.html

> In the same bucket of regularisation: every inode metadata command uses
> «-c» to mean "verbose but only if it changes", EXCEPT «touch», where it's
> "don't create". I don't suppose we could have a uniform
> «--verbose=ifchanged»?

Interesting. Though touch doesn't have any --verbose option yet,
so I'm not convinced there is a pressing need for that?
>> Secondly, I note that 'touch -r' copies the atime and mtime separately;
>> it would be nice to be able to have --atime= and --mtime= as separate
>> options, as an alternative to both combined as --time=.
>>> Again, I can provide a patch if this would be acceptable.
>>
>> I don't understand this request.
>>
> 
> Currently it takes two invocations of ‘touch’ to change the atime and mtime
> to different values, UNLESS you're using -r in which case just one
> invocation will suffice: touch -r copies the reference's mtime onto the
> target's mtime, and the reference's atime onto the target's atime.
> 
> The idea would be to be able to perform this using explicit values for
> atime and mtime separately rather than using a reference file.
Ah right. Given that's not often needed, and a perf only change,I'm not sure that's warranted.

Thanks for taking the time to consider the touch interface so carefully.

cheers,
Padraig

Previous Next

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