Prevent a user from deleting a file in his home directory

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

and the file is gone.
The user is

[seuser@fedora ~]$ id -Z
user_u:user_r:user_t:s0

Thanks for your help.

have a look at chattr

chattr +i specialfile

Here is some info from the man pages :exclamation:

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.

5 Likes

Thanks, that works really well and I am using it now :slight_smile:

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.

It is probably because they either own or have write rights on the directory containing the file.

4 Likes

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.

4 Likes

see:
https://www.tutorialspoint.com/unix/unix-file-permission.htm

write for a file
versus
write for a dir

3 Likes

when they are NOT in an subdir owned by root

[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'



The quote you took is out of context. With the context in which it came it could be rewritten as:

In other words, I think it is possible to delete files you can’t read/write if you have write access to the directory containing the file.

As a side note, it doesn’t matter if the directory is owned by root, it only matters if you have write access to the directory.

For example:

>> sudo chown root:root testfile                                                                                                                                                                                               
>> sudo chown root:root .                                                                                                                                                                                                 >> rm testfile                                                                                                                                                                                                                 
rm: remove write-protected regular empty file 'testfile'? y
rm: cannot remove 'testfile': Permission denied
>> sudo chmod o+w .                                                                                                                                                                                                         >> rm testfile                                                                                                                                                                                                                 
rm: remove write-protected regular empty file 'testfile'? y

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:

3 Likes

My intentions was to sensible the OP regarding file/dir rights/ownership

1 Like