24

I have this file:

$ ls -l  store.sh 
-rwxr-xr-x   1 root apache    117 Feb  5  2016 store.sh

$ id
uid=48(apache) gid=48(apache) groups=48(apache)

I think that I haven't the permission to edit this file but was possible delete and replace the file. How can it be? Can someone explain this behaviour?

Improve this question
0

2 Answers 2

Reset to default
51

You don't need write permissions on a file to delete or move (rename) it. You need write permissions on the directory containing the file, because deleting or renaming are not operations on the file, but operations on the directory's list of files. So in this case the directory of this file probably has write access for the apache user or the apache group.

Improve this answer
12
  • 5
    @ErelSegal-Halevi but you actually haven't. In particular if the same file was also linked under a different name, possibly in a different directory, it is still there unchanged. Or if it was opened by some process, the process still accesses that file, not the new one you created.
    – Michał Politowski
    Feb 6, 2018 at 11:04
  • 6
    @ErelSegal-Halevi: Files don't have names: directory entries have names. You can change which file a directory entry points to, but that doesn't change the file at all, and it doesn't affect any other pointers to that file (e.g. other links to the file or programs that have it open).
    – user378002
    Feb 6, 2018 at 11:04
  • 4
    @RonJohn: absolutely not. You should have the rights on the directory that you need to have, no more, no less. Admins will need to monitor and change the rights on the directories to really match the needs and the security they want. That the OP could delete a file he couldn't edit is not broken, but it may point out that the rights on his server (on that particular tree branch) may not really be well set up.
    – Olivier Dulac
    Feb 6, 2018 at 11:55
  • 5
    @RonJohn That's when it turns out you finally need to read up on SELinux security contexts/policies.
    – moooeeeep
    Feb 6, 2018 at 12:20
  • 6
    @Ron it's not broken, it's limited. There are a certain set of use cases that are served very well by POSIX permission schemes, and some use cases which need ACLs on top of those, and some which can't be done with either, so you need to rework the directory structure and ownerships around those limitations. It's a reasonable compromise between of simplicity of implementation and simplicity of use.
    – Olorin
    Feb 6, 2018 at 12:52
0

Deleting a file doesn't modify the file in question rather it modifies the parent directory as it removes the file from directory listing. This also means that you have full permissions to the parent directory of the file

Improve this answer

Not the answer you're looking for? Browse other questions tagged or ask your own question.