Re: Bug in rm command ?

[Bob Proulx]

Thanks for the report.  But what you are seeing is normal.

> The system

You included a wonderful amount of information.  Thank you very much!

> We create a file in the home of mike called rootfile, this file is owned bij
> root
> 
> echo test > /users/mike/rootfile
> 
> We log in as the user mike
> 
> bash-2.04$ whoami
> mike
> bash-2.04$ ls -l
> total 4
> -rw-r--r--    1 root     root            5 Apr 16 12:17 rootfile
> 
> now we delete the file rootfile (this should be impossible !)

What is the permission on the directory that is holding 'rootfile'?

> How is this possible ?

Check the permission of the directory.

  ls -ld
or
  ls -la

I am sure you will find it writable by mike.  The file was not
writable and you never wrote to it.  The file was held in a container
which you could modify and did.  This is not entirely unlike a glass
safe.  You can see into the safe and look at the contents.  You can't
get into the safe to modify it.  But you can throw the safe away
without ever opening it.

If you want to prevent removal of files from a directory then you need
to remove write permission from the directory.  The filesystem itself
is reference counted and when the last reference to a file goes away
it frees up the disk blocks.

> Is there something I do wrong or is it a serious bug in the rm command or in
> the file system ?

Since rm is just a user program there *can't* be a security problem
with it, as long as it is not suid which would increase the level of
access available.  A user could always use something like:
  perl -e 'unlink "rootfile";'
to remove the file without ever invoking the rm program.  Perl is just
one example.  The security must reside with the prison system and not
with the inmates.  Something to think about.  Many of the unix command
set only provide command line access to the underlying system calls.
The rm command provides a command line user interface to the unlink(2)
kernel system call.  You can do anything that it allows you to do.
The security is in the operating system.

Also note that rm checks the file permission and asks the yes-no
question if it is a non-writable file only as a courtesy.  It does not
need to ask.  Other programs such as the perl snippet won't ask unless
the author codes that question up there too and as you can see my
oneliner didn't.

You are not the first to notice the design challenge of making
permissions work intuitively.  AFS, another type of filesystem, uses
access control lists (ACLs) extensively.  The new CODA filesystem
derives heritage from AFS.  Many people find those more intuitive.
The permission system is definitely different from traditional unix
filesystems.  You might enjoy checking those out and comparing the
differences.  But none as as overwhelmingly pervasive as the
traditional unix filesystem and so software support for ACLs is
minimul in most programs.

Bob