25 May
2017
25 May
'17
12:23 a.m.
Ok, I just did an experiment with the rm command and the results surprised me.
On Unix v5 logged in as root I created a small test file then did
chmod 444 on it. Unfortunately it appears that mere users can still rm
the file and also directories are not safe from the rmdir command
(even directories set to mode 444).
This seems to be the case for v6 and v7 as well.
To be fair rm will prompt the user with: test1: 0100444 mode
but the user only has to type y and hit enter and the file is toast.
Is there no way to completely protect files from being deleted?
Mark
12:48 a.m.
On Wed, May 24, 2017 at 8:23 PM, Mark Longridge <cubexyz(a)gmail.com> wrote:
Ok, I just did an experiment with the rm command and
the results surprised
me.
On Unix v5 logged in as root I created a small test file then did
chmod 444 on it. Unfortunately it appears that mere users can still rm
the file and also directories are not safe from the rmdir command
(even directories set to mode 444).
This seems to be the case for v6 and v7 as well.
To be fair rm will prompt the user with: test1: 0100444 mode
but the user only has to type y and hit enter and the file is toast.
Is there no way to completely protect files from being deleted?
Yes, these are the normal semantics, even on modern systems. If you want to
prevent a user from removing a file, remove the user's write permission to
the directory containing the file. Recall that a "file" in the removable
sense is really a directory entry that points to the inode that represents
the real file; to remove that, one must modify the directory to remove the
directory entry. The permissions on the file itself don't matter since
removal isn't an operation on the contents of the file; the only thing it
does to the actual file is update the link count in the inode.
- Dan C.
12:57 a.m.
You have to understand that you can’t directly delete a file in UNIX. It’s never worked
that way.
What you can do is remove the directory reference (in UNIX terms, a link) to the file.
When the link count goes to zero, the inode (which embodies the storage and permissions,
etc..) of the file then gets freed up (along with the data blocks comprising the file).
The inode permissions of the file have NEVER had any bearing on whether it can be unlinked
or not. The permission to unlink is that of the directory that contains it. If the
directory is writable, the file can be unlinked from that directory. If that’s the last
link, the file goes away.
RM in many versions checks to see if the file is read only and asks if you are sure, but
that is an artificial safety net done by the rm program (which is not present in the
unlink system call itself).
1:36 a.m.
On Wed, 24 May 2017, Mark Longridge wrote:
Ok, I just did an experiment with the rm command and
the results
surprised me.
[...]
It's always been the case that you need write permission on the parent
directory; after all, it's what you are actually updating.
Is there no way to completely protect files from being
deleted?
Don't make the parent directory writable... And if your OS supports file
attributes I believe there's an "immutable" flag.
--
Dave Horsfall DTM (VK2KFU) "Those who don't understand security will
suffer."
2527
days inactive
2527
days old
4 comments
5 participants
participants (5)
-
Christian Groessler -
Dan Cross -
Dave Horsfall -
Mark Longridge -
Ron Natalie