I have a file which I place in new users’ home directories and would like to prevent them from deleting said file. Read access needs to remain possible. The users are not administrators (cannot sudo). I tried by creating a file as root and setting permissions 644, but the user can still delete the file (after a confirmation). I even tried restricting the user to be of SELinux user user_u, but to no avail. Any ideas of how else I could protect that file?
Here some output of me deleting the file as the restricted user:
[seuser@fedora ~]$ ls -lZ
total 4
-rw-r--r--. 1 root root unconfined_u:object_r:user_home_t:s0 8 Jun 28 10:06 specialfile
[seuser@fedora ~]$ rm specialfile
rm: remove write-protected regular file 'specialfile'? y
CHATTR(1) General Commands Manual CHATTR(1)
NAME top
chattr - change file attributes on a Linux file system
SYNOPSIS top
chattr [ -RVf ] [ -v version ] [ -p project ] [ mode ] files...
DESCRIPTION
chattr changes the file attributes on a Linux file system.
The format of a symbolic mode is +-=[aAcCdDeFijmPsStTux].
The operator '+' causes the selected attributes to be added to
the existing attributes of the files; '-' causes them to be
removed; and '=' causes them to be the only attributes that the
files have.
Thanks, that works really well and I am using it now
It does not quite solve my puzzle why an unprivileged user can delete the root owned file in the first place, but I guess that has something to do with capabililties, probably cap_dac_override. Though I am wondering why an unprivileged and even selinux restricted user could use such capability.
Indeed, it is the write access to the parent directory which allows the user to remove the file. That is very interesting. So a user has write permission to any file where he has write permission to the parent directory. That is quite surprising. I thought if I revoke write permissions to a file, then the user would not have write permissions to that file.
That is probably true, but isn’t deleting a file a modification to the directory? In other words, I think it is possible to delete files you can’t read/write.
[ron@obelix Downloads]$ ls -lR
.:
total 0
drwxr-xr-x. 1 ron ron 12 29. Jun 04:31 testdir
./testdir:
total 0
drwxrwxr-x. 1 ron ron 6 29. Jun 04:30 a
drwxrwxr-x. 1 ron ron 6 29. Jun 04:31 b
drwxrwxr-x. 1 root root 6 29. Jun 04:20 c
-rw-rw-r--. 1 root root 0 29. Jun 04:31 ddd
./testdir/a:
total 0
-rw-rw-r--. 1 ron ron 0 29. Jun 04:30 aaa
./testdir/b:
total 0
-rw-rw-r--. 1 ron ron 0 29. Jun 04:31 bbb
./testdir/c:
total 0
-rw-rw-r--. 1 root root 0 29. Jun 04:20 def
[ron@obelix Downloads]$ rm -rvf testdir
rm: cannot remove 'testdir/c/def': Permission denied
removed 'testdir/a/aaa'
removed directory 'testdir/a'
removed 'testdir/b/bbb'
removed directory 'testdir/b'
removed 'testdir/ddd'
Yes, I can delete files which I cannot read. I can also delete a directory to which I have no access, if it is empty. If there is a file in that directory, than I cannot delete it, but still rename it (moving to a different location does not work). Kind of gives me a side channel to check whether a directory to which I have no access is empty.
thanks, need to be careful when reading that. So file access (read and/or write) is only for the content of the file, whereas directory access is for the files within that directory. So in some cases I can only remove the entire file, not just parts of it. Somewhat confusing. Especially that file permissions do not quite protect the file content; it can still be removed altogether.
You can also look at the sticky bit for that purpose. If sticky bit is set on a directory, only the directory owner, root user or the file owner can delete/rename a file on that directory. Other users cannot do anything regardless of whether they have write access to that directory or not:
