23

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.

Improve this question
5
  • 1) This is off-topic. 2) I very much doubt that you were able to delete that as non-root user without sudo or other privilege escalation. You probably overlooked something.
    – DarkDust
    Dec 19, 2011 at 13:11
  • 17
    @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
    Dec 19, 2011 at 13:13
  • @nos: Silly me, you're right.
    – DarkDust
    Dec 19, 2011 at 13:14
  • 1
    An 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
    Dec 19, 2011 at 14:59
  • @DavidSchwartz that's true, but deleting the file from the directory is about removing the reference in the directory structure.
    – mc0e
    Apr 23, 2017 at 11:47

2 Answers 2

Reset to default
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.

Improve this answer
6
  • 1
    And 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
    Dec 20, 2011 at 1:32
  • 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
    Dec 20, 2011 at 2:21
  • "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
    Aug 23, 2018 at 17:40
  • @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
    Aug 23, 2018 at 18:11
  • 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
    Aug 23, 2018 at 18:43
1

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.

Improve this answer

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .