[TUHS] can't protect files from deletion v5,v6, or v7

[TUHS] can't protect files from deletion v5,v6, or v7

[Mark Longridge]

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

[TUHS] can't protect files from deletion v5,v6, or v7

[Christian Groessler]

On 05/25/17 02:23, Mark Longridge wrote:

> Is there no way to completely protect files from being deleted?

There is a way, write-protect the directory. What else?

regards,
chris

[TUHS] can't protect files from deletion v5,v6, or v7

[Dan Cross]

On Wed, May 24, 2017 at 8:23 PM, Mark Longridge <cubexyz at 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.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://minnie.tuhs.org/pipermail/tuhs/attachments/20170524/30b9b65b/attachment.html>

[TUHS] can't protect files from deletion v5,v6, or v7

[Ron Natalie]

[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #1: Type: text/plain, Size: 1051 bytes --]

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).

 

 

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://minnie.tuhs.org/pipermail/tuhs/attachments/20170524/c41748ff/attachment.html>

[TUHS] can't protect files from deletion v5,v6, or v7

[Dave Horsfall]

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."