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.
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@1wt.eu 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.
On Tue, 15 Aug 2023 at 06:11, Xuancong Wang xuancong84@gmail.com wrote:
Yes, by "full access", I mean `chmod 777`. You can easily reproduce this bug on any Linux machine by typing the following commands:
This is how things are supposed to work. The 0777 permissions mean that you can read, write and execute the file. They do not mean that you own the file.
As a non-owner, you can set the access and modification times the same way you could by just reading and writing to the file. So if you set mtime, you have to set ctime ("change time") too.
To actually change times arbitrarily and with other patterns, you need to actually own the file.
Linus
Thanks Torvalds for your clear-cut answer, I really appreciate that.
On another hand, I would like to suggest that Linux files should have an additional permission bit to be granted arbitrary attributes access, especially for the atime, ctime and mtime. The reason is because in production data pipeline, we often need multiple people to get/set the same file's modification times arbitrarily (e.g., set an output file's mtime according to the input file for incremental processing), and this process is managed by several people. So now, we have to run our data processing pipeline as root which is risky and undesirable.
This can be implemented either: - as a single bit in file attributes along with the 7777 (i.e., setUID bit, setGID bit, sticky bit, user-3-bits, group-3-bits, others-3-bits), I would call it group-attribute-bit to allow users in the same group to modify its timestamp arbitrarily. or - as an extra bit in user/group/other, so that it become 7FFF (it is nice to have 4-bits for user/group/other, because 4 bits make up for one hexadecimal digit😁)
Thank you very much for your consideration!
Cheers, Xuancong
On Tue, Aug 15, 2023 at 2:29 PM Linus Torvalds torvalds@linuxfoundation.org wrote:
On Tue, 15 Aug 2023 at 06:11, Xuancong Wang xuancong84@gmail.com wrote:
Yes, by "full access", I mean `chmod 777`. You can easily reproduce this bug on any Linux machine by typing the following commands:
This is how things are supposed to work. The 0777 permissions mean that you can read, write and execute the file. They do not mean that you own the file.
As a non-owner, you can set the access and modification times the same way you could by just reading and writing to the file. So if you set mtime, you have to set ctime ("change time") too.
To actually change times arbitrarily and with other patterns, you need to actually own the file.
Linus
linux-stable-mirror@lists.linaro.org
-
Linus Torvalds -
Willy Tarreau -
Xuancong Wang