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
