4

today to my surprise I have noticed that I may delete a file that was created by a user with UID 100024 while being logged to my normal user (UID 1000) shell. The UID 100024 is a subuid, it is how the user inside the rootless podman container looks in top processes, also in ls -l output. The cat /etc/subuid out is myuser:100000:65536, same for the subgid. The sudo sysctl kernel.unprivileged_userns_clone out is kernel.unprivileged_userns_clone = 1 the getfacl /the/file shows

user::rw- group::r-- other::r--

The grep CONFIG_USER_NS /boot/config-$(uname -r) out is CONFIG_USER_NS=y.

To even a bigger surprise, I was able to edit a file created by UID 1000 user in the volume mapped folder, from inside the container! The file had 644 permissions and was owned by nobody:nogroup. I'm pretty sure I could not do these operations in the past. Anything has happened to my 6.1.0-32-amd64 Debian? The filesystem is xfs.

ls -hal for the directory returns:

drwxrwxr-x+ 12 pod_yt root 4.0K Jul 19 17:09 name_of_the_dir

and the getfacl for the dir returns

user::rwx user:myuser:rwx user:name_of_the_user_for_uid_100024:rwx group::r-x mask::rwx other::r-x
Improve this question
0

1 Answer 1

Reset to default
9

There’s probably an existing Q&A that explains this but I can’t find it. Why can rm remove read-only files? addresses the first part but not the second.

You can delete files belonging to another user because you have write permissions on the containing directory, and the sticky bit isn’t set on the directory: deleting a file is a change in the directory, it doesn’t require permissions on the file itself.

The same applies to editing files; many editors update files not by writing to the existing file, but by creating a new file with the updated contents, and renaming that file over the old one. Since you have write permissions on the directory, this works fine (perhaps with a warning from some editors).

Improve this answer
6
  • How to fix it: sudo setfacl -x u:myuser /the/dir. As one may see im my reply to your comment above, the reason was ACL permission to myuser over the directory. Could it have make POSIX permissions available to the myser just as to the owner by UID? Commented Jul 29 at 14:33
  • 1
    I’m sorry, I don’t understand the question. Are you asking about POSIX permissions instead of ACLs? POSIX permissions can’t assign permissions to specific users other than the file owner. Commented Jul 29 at 14:37
  • Also the notion of the preference for the directory permissions over the file permissions is important. Vim has truly been creating the file owned by the editiing user, after asking for an override option !. Commented Jul 29 at 14:44
  • 2
    No, ACL permissions are self-sufficient. Some ACL permissions are tied to corresponding POSIX permissions, but that only affects their updates, not how they’re interpreted when used. man 5 acl describes ACLs in detail (but it’s a difficult read). Commented Jul 29 at 14:52
  • 3
    You can delete files belonging to another user because you have write permissions on the containing directory ... and the sticky bit isn't set on the dir, like it would be in /tmp or /var/tmp to stop you from doing this. @Václav, chmod 1775 /.../shared_dir might be what you're looking for. (I haven't used ACLs, IDK if there'd be any interaction that would make the sticky bit not work that way.) Commented Jul 29 at 23:45

You must log in to answer this question.

Start asking to get answers

Find the answer to your question by asking.

Ask question

Explore related questions

See similar questions with these tags.