Re: chmod: expected behavior for no change?

[Dragan Simic]

Hello,

On 2024-03-09 10:00, Bernhard Voelker wrote:
> In [1], the point is raised why the following fails (as a 
> non-privileged user):
>
> > $ chmod a+x /usr/bin/ls
> > chmod: changing permissions of '/usr/bin/ls': Operation not permitted
> >
> > However, /usr/bin/ls is already executable, there is no need to change 
> > permissions,
> > hence no need to report a problem with changing permissions.
>
> I consider that as question Q2 (see below).
>
> Looking at strace output, we see that chmod(1) already uses the stat 
> family
> to determine ST_MODE:
>
>   umask(000)                              = 022
>   newfstatat(AT_FDCWD, "/usr/bin/ls", {[...], st_mode=S_IFREG|0755, 
> [...]) = 0
>   fchmodat(AT_FDCWD, "/usr/bin/ls", 0755) = -1 EPERM (Operation not 
> permitted)
>
> So the first question Q1 is:
>   Does chmod(1) need to invoke fchmodat(2) at all if it knows that the 
> ST_MODE
>   is already in desired state?
>
> Reading the POSIX spec [2], I don't see any mention of either topic Q2 
> or Q1.
> OTOH if fchmodat(2) does get called, then we IMO should diagnose the 
> error.
>
> My first reaction without more thinking:
> As this is historic behavior, and maybe even someone relying on that 
> behavior,
> we should not change the behavior.
> I'd rather have this clarified in the docs or even better in the spec 
> [2].
> If someone calls chmod(1), it's calling chmod(2) or fchmodat(2) and 
> therefore
> wants to know the result from the kernel and file system.  Straight 
> rule.
>
> WDYT?

To me, reporting such errors is fine.  You're asking chmod(1) to do 
something
it isn't allowed to do, regardless of that already being satisfied or 
not.  It's
somewhat like invoking rmdir(1) on a directory that already doesn't 
exist.

> [1] https://bugzilla.suse.com/show_bug.cgi?id=1220209
> [2] 
> https://pubs.opengroup.org/onlinepubs/9699919799/utilities/chmod.html