24
6
Given a non-root user "joshua", as root I created a file called "foo" at joshua's home directory (/home/johsua/); it look like this:
-rw-r--r-- 1 root root 0 12-19 21:00 foo
and then delete it as joshua, i can delete it successfully.
I would expect that joshua doesn't have enough permission to delete it. Is it some kind of 'Permissions inheritance'? My platform is Debian 5.0.7.
Joshua
Posted 2011-12-19T13:08:28.130
Reputation: 243
43
The user didn't delete the file, the system did. The user merely removed the file from his own directory. The system deleted the file because its reference count dropped to zero. It's just happenstance that the user removing the file from the directory happened to drop its reference count to zero. (If the file was hard linked to another directory or a handle was opened to the file, it would not have been deleted.)
The system deletes files automatically when their reference counts drops to zero. The owner of the file doesn't matter. There are many ways someone other than the owner of a file can drop the file's reference count to zero.
Removing a file from a directory (called 'unlinking') is an operation on the directory. Unlinking a file reduces its reference count.
Similarly, a user other than the owner could close the last handle to a file that isn't linked to any directories. Closing that handle would delete the file as well, since again the reference count would drop to zero.
David Schwartz
Posted 2011-12-19T13:08:28.130
Reputation: 58 310
"The user didn't delete the file, the system did" This makes no sense. The "system" cannot make changes that require privileged access on behalf of unprivileged user. As such, this answer will fail to explain why the same user can't do the same if the current directory was owned+writable only by root.
The answer below by @kerrek is accurate and concise. – FractalSpace – 2018-08-23T17:40:06.370
@FractalSpace Huh? The system can make changes that require privileged access on behalf of an unprivileged user and does so all the time. For example, changing the bytes on a disk requires privileged access. However, if a user can modify a file, the system will decide to modify some bytes on the disk even though the user doesn't have permission to modify those bytes themselves. A user can't modify kernel memory, but the kernel can when executing on behalf of a user. Systems operate by deciding to perform operations their users cannot directly authorize. – David Schwartz – 2018-08-23T18:11:58.063
Yes. And eventually everything is done by the "system". But not before going through strict privilege separation rules set for that particular "user space". In this scenario, e.g, "system" is not making action as a general rule, but it is following the permissions set on the "parent directory". The key part of this issue in OP question. – FractalSpace – 2018-08-23T18:43:37.650
@FractalSpace No, the system is performing the action as a general rule, not because the user asked it to. The general rule (enforced by the file system) is that files are deleted when they have no references. The user removed one reference because that particular reference was something he had permission to remove, as my answer explains. (The file would not be deleted if there were other references to it.) Kerrek's answer is wrong for the reason I explained in my comment on it. It substitutes the OP's original confusion for a new confusion. – David Schwartz – 2018-08-24T16:16:23.500
1And of course the rm command muddies the waters a bit, because rm is an abbreviation of "remove", and users are trained to think of rm as a "delete" operation. Many users use rm every day while being unaware that the operation it actually performs is an "unlink", not a "delete". As a result, it shouldn't really be surprising that many users find this behavior surprising when they first encounter it. – Daniel Pryden – 2011-12-20T01:32:39.600
It is definitely surprising to many people. At least the rm command does in fact remove a file or directory from a directory. It's worse on Windows where the command is called del, because it used to delete a file but on modern Windows machines (since NT4), it's also an unlink operation. – David Schwartz – 2011-12-20T02:21:47.310
0
First guess: For deleting a file you need write permissions on the containing folder. So Try /home/johsua/foo/bar, give 755 to foo and 644 to bar.
Eugen Rieck
Posted 2011-12-19T13:08:28.130
Reputation: 15 128
@DavidSchwartz that's true, but deleting the file from the directory is about removing the reference in the directory structure. – mc0e – 2017-04-23T11:47:16.420
>
sudoor other privilege escalation. You probably overlooked something.16@DarkDust A file is an entry in its parent directory. If you have write rights in a directory, you can remove files in it regardless of who owns the files (unless the sticky bit is also set on the directory) – nos – 2011-12-19T13:13:02.300
@nos: Silly me, you're right. – DarkDust – 2011-12-19T13:14:28.420
1An entry in its parent directory is a reference to a file. It is not the file itself. (Otherwise, how could a file be hard linked to more than one directory?) – David Schwartz – 2011-12-19T14:59:12.697