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?
[1] https://bugzilla.suse.com/show_bug.cgi?id=1220209
[2] https://pubs.opengroup.org/onlinepubs/9699919799/utilities/chmod.html
Have a nice day,
Berny
