Yes, by "full access", I mean `chmod 777`. You can easily reproduce
this bug on any Linux machine by typing the following commands:
xuancong@mx:~$ sudo su
root@mx:/home/xuancong# echo yes >a
root@mx:/home/xuancong# chmod 777 a
root@mx:/home/xuancong#
exit
xuancong@mx:~$ echo no >>a
xuancong@mx:~$ cat a
yes
no
xuancong@mx:~$ ls -al a
-rwxrwxrwx 1 root root 7 Aug 15 14:08 a
xuancong@mx:~$ touch -m a
touch: setting times of 'a': Operation not permitted
xuancong@mx:~$ python -c "import os,sys;os.utime('a',(1,1))"
Traceback (most recent call last):
File "<string>", line 1, in <module>
PermissionError: [Errno 1] Operation not permitted
Cheers,
Xuancong
On Tue, Aug 15, 2023 at 1:31 PM Willy Tarreau <w@xxxxxx> wrote:
>
> Hello,
>
> On Tue, Aug 15, 2023 at 11:42:55AM +0800, Xuancong Wang wrote:
> > Dear all,
> >
> > I found in all versions of Linux (at least for kernel version 4/5/6), the
> > following bug exists:
> > When a user is granted full access to a file of which he is not the owner,
> > he can read/write/delete the file, but cannot "change only its last
> > modification date". In particular, `touch -m` fails and Python's
> > `os.utime()` also fails with "Operation not permitted", but `touch` without
> > -m works.
> >
> > This applies to both FACL extended permission as well as basic Linux file
> > permission.
> >
> > Thank you for fixing this in the future!
>
> Your description is unclear to me, particularly what you call "is
> granted full access": do you mean chmod here ? If so, you can't
> delete it, so maybe you mean something else ? You should share a
> full reproducer showing the problem. Also, the fact that one
> command (touch) works and another one (python) does not indicates
> they don't do the same thing. So I suspect it's more related to
> the way the file is accessed where both commands use different
> semantics. As such, using strace on both commands showing the
> sequence accessing that file will reveal the difference and very
> likely explain why one can and the other cannot change the last
> modification date.
>
> Willy
>
> PS: there's no need to keep security@ here, it's used to dispatch
> issues to maintainers and coordinate fixes, now that your report
> is public it will not bring anything anymore.
