Why are protected files being deleted?

Rocky Linux General
1

I’m having a rather odd situation on a newish server and I can’t figure what I may have misconfigured. A user who IS NOT root can delete files owned by other users for which they have no authority. As an example that actually happened tonight:

Blockquote ls -al hnylorders.txt
-rw-r–r–. 1 root root 0 Feb 14 22:04 hnylorders.txt
[John@prod02 ~]$ cat hnylorders.txt
[John@prod02 ~]$ rm hnylorders.txt
rm: remove write-protected regular empty file ‘hnylorders.txt’? y
[John@prod02 ~]$ ls -l hnylorders.txt
ls: cannot access ‘hnylorders.txt’: No such file or directory

John is definitely NOT the root user which owns this file and does not have sudo privileges. In this case the file was empty so no loss but I do depend on the standard protections to avoid accidents to my data! Any ideas folks? Forgot to mention selinux is in permissive mode on this server.

2

Do you have any acls set?

3

You can try typing getfacl . in the current directory to see what access controls those files might have.

4

No ACL’s deliberately, this is a rather vanilla installation. I wanted to check if the file being empty triggered this so I created another file owned by root:

Blockquote
ls -al ./test-test1.txt
-rw-r–r–. 1 root root 10 Mar 26 20:24 ./test-test1.txt
[John@prod02 ~]$ rm ./test-test1.txt
rm: remove write-protected regular file ‘./test-test1.txt’? y
[John@prod02 ~]$ ls -al ./test*
ls: cannot access ‘./test*’: No such file or directory

So I checked using getfacl:

Blockquote
getfacl -a ./test*.txt

file: test-test2.txt

owner: root

group: root

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

[John@prod02 ~]$ rm ./test-test2.txt
rm: remove write-protected regular file ‘./test-test2.txt’? y
[John@prod02 ~]$ ls -al ./test*
ls: cannot access ‘./test*’: No such file or directory

Once again user John was able to remove it without authority. Files on this directory (which is owned by user John) are written by an FTP service from a server that we don’t own or control so I want to be a bit careful as to what the permissions really do.

5

I can duplicate this on my F39 laptop. So it seems that in a users home they have authority to delete or rename files not owned by them. They cannot change ownership or add or change content. I think you need to rethink where you download content to.

6

Thanks, and totally unexpected! I just checked on the Fedora 17 server here and exactly the same result so your answer is correct. Since user John actually processes these FTP files this is OK I suppose but I will see if I can find a better solution.

7

The userhome is not “special”. It is the permission attributes of the directory. They were not shown here.

The filename is metadata about file. A handle. If we rename a file, we do not modify the data of the file,
but we do modify the data of the directory that “has” the filename. Therefore, anyone with modify access
(w) for the directory can do that.

Look at /tmp. It has write access for everyone. So, anyone can remove all files from /tmp?
No, it has also sticky bit set – only owner of file can remove the file from such directory.

Then there are also the ACLs for more “fun”.

Is that 17 a typo, or is it an ancient setup that has no access to public network?

8

No, Fedora 17 is not a typo. That is the server that is currently in use that this new one will replace eventually when I get everything working. At the moment some remote access (FTP for example) is on the new one and some is on the old one. Since I started to build the new one in April, 2023, things have sort of gone pear-shaped on me here so the server gets attention when time permits. One thing I noticed on Rocky 9 is that smartctl can’t seem to read the info for the WD Blue SSD’s, according to it they all have less than 100 hours on them after nearly a year of operation and some of the data displayed doesn’t make sense.

9

Sorry late to the party if you want a file that no one can delete (not even root) do sudo chattr +i file.txt

The only way to remove it will be doing a chattr -i first

This is handy when for instance working with something like puppet or ansible and you want certain files not to be overwritten or removed

Hope it helps!

10

Thanks Alexia. Learned a lot here and I need to think about exactly what I need to accomplish. Eventually the files have to be deleted of course. Initially they are sanitized from the remote files by cron running as root and that is what caught my attention, I was able to delete a file that I didn’t own; now I know why. Hadn’t heard of chattr before, appreciated.

11

This part probably made it more confusing:

You are printing info about a specific file.
Whereas this command
ls al
on it’s own, would have shown details of the containing directory (just dot), which would probably show ownership as the standard user.
The reason you get the waring about the file being “write-protected” is because the permission bits are set to only allow ‘root’ to have ‘rw’ access. If you try to write to that same file as the standard user it will probably give an error.

12

This is standard behavior since the early days of Unix in the 1970’s. The permission to remove or rename a file in a directory is determined by the permissions of the directory, not the permissions of the file.

This behavior was slightly changed in 1986 in 4.3 BSD Unix, when the behavior of directories with the sticky bit set (e.g. drwxrwxrwt) means that only the owner of a file (or root) may remove or rename that file.

1 Like