Root-owned file vulnerable under user dir

[Jakes Louw]

Is this normal:

A file owned by root is resident under a user directory.
The user (owner of the parent directory) can delete the root file, even though he obviously is not the owner and does not have super-user privileges.

The root-owned file also has persmissions set of "chmod 100": execute for root only, no other permissions, no SUID bits, nothing.

I can reproduce this at will.
Are we saying then that if you own a directory, you can delete the contents at will, regardless of ownership?

This isn't how I've understood UNIX security over the last 10 years.

This server is running 11.11 with Dec 2002 GPK, no extras.

What am I missing?

[Mark Grant · Accepted solution]

Not if you set the sticky bit on the directory itself. Set this sticky bit and only the owner can delete it.

[Sanjay Kumar Suri]

Whew...

It is normal. And this is how it works on my system as well except the following difference in my case:

$rm sss
sss: 644 mode ? (y/n) y

FILE gone.

sks

[Jeroen Peereboom]

Jakes,

this is normal behavior. Deleting a file means writing in its directory.
As Mark says you should set the sticky bit on the directory (chmod u+t).
According to the man page, the owner of the file, the owner of the directory or superuser can remove the file (even if the modes of the directory would otherwise allow such operation).

To be honest I learned about the sticky directory bit on a Linux course...

JP.

[KapilRaj]

Unless you have sticky bit on the directory, this is normal as the owner of the directory have write parmission on the directory!

Regds,

Kaps

[Jakes Louw]

OK, I just set the sticky on that dir :

chmod u+t .....

and the guy can STILL delete a file touched by root.

WHAT NOW?

[Mark Grant]

Try "chmod u+s" instead :)

[Mark Grant]

Apologies for being dumb today. It should be the "t" not the "s" of course.

The actual definition is that when the sticky bit is set in a directory, only the owner of the file AND the owner of the directory can remove the file.

[Jeroen Peereboom]

Jakes,

the owner of the directory can remove root's file in that dir. Check the manpage of chmod on sticky bit.
According to the man page, the owner of the file, the owner of the directory or superuser can remove the file (even if the modes of the directory would otherwise allow such operation).

Jeroen P.

[Jeroen Peereboom]

Hmm,

maybe I should add the word ONLY:
ONLY the owner of the file, the owner of the directory or superuser can remove the file (even if the modes of the directory would otherwise allow such operation).

So if the directory is group-writable, members of the group cannot delete root's file if the directory has sticky bit.

Regardless of the file's protection, the directory owner can remove the file (if the directory has sticky bit or if the owner has write access to his/her own directory).

JP

[Bill Hassell]

This is a very basic concept of Unix filesystems. The file's ownership and permissions govern the CONTENTS only. The EXISTENCE of a file is governed solely by the directory's permissions and ownership. That's why you can't protect .profile in the user's $HOME directory. You can make a file 444 permissions with root as the owner so the contents can't be change but the user can simply mv or rm the file and create their own .profile. As mentioned, you can add the sticky bit to the directory and now mv and rm will not work if the file has a different owner (such as root). This bit is a common sysadmin enhancement for /tmp and /var/tmp, less common for $HOME but may be useful.

[Hazem Mahmoud_3]

A good way to think of it is that all "objects" on Unix are just files. Therefore, even directories can be considered as files. Therefore, the owner of the directory can modify the file (ie: directory) contents by adding/deleting contents inside of it, just like how you can add/remove contents in a normal flat file if you are the owner of that file. If you think about it that way, it makes a lot of sense.
Just a reiteration on what Bill has already mentioned.

-Hazem

[Rory R Hammond]

FYI

You make it sound like a bad thing that the owner can remove a root owned file from his "domain".

As a application owner, or a owner of a directory. you better believe, I want to be able to remove "ANY" file in "MY" directories. futher more, I don't want root to be able to put anything in "MY" space.

Permissions are also designed to protect the user. In my mind, the only exception should be "lost+found" on file systems owned by a user or application. Then as an administrator (root), I encourge the user to leave it alone.

Now, If I am a "rogue" user, Then lets talk restricted shell, and files that I may use.


Good Luck
Rory