sticky bit on files to stop deletion

[Scott Van Kalken]

I have a weird question to which I think there is now answer.

I have been asked to find out if there is any way that we can stop people deleting files while still giving people write access to them.

As always nobody listens to me whinge whinge :)...

I am of the opinion that since HPUX does not have a seperate permission for "delete" it only has rwx, that it can't be done.

Essentially I want people to still be able to update a file, but not delete it.

I can't think of any realistically possible way of doing this.

If HPUX were like novell or VMS where a seperate permission exists for delete then it would be possible, but I don't think it does.

Please correct me if I'm wrong, or come up with a better solution.

[Steven Sim Kok Leong]

Hi,

One way is to install a tool previously known as Platinum AutoSecure that provides additional restrictions on top of OS permissions (eg. restricting what the superusers of uid 0 such as root can perform) as well as auditing. For this, you need to assign a separate security officer to delegate permissions.

One alternative is to create a menu-driven interface for the user so that the user is restricted to the set of menu items for execution and can only modify the file but not remove it simply because there is no menu option to remove the file.

Hope this helps. Regards.

Steven Sim Kok Leong

[harry d brown jr]

Scott,

>>>>>>I have been asked to find out if there is any way that we can stop people deleting files while still giving people write access to them.<<<<<<

This is done by following basic security procedures: "Keep people from having access to a unix shell!" It's worked for me for the past 15 years!


live free or die
harry

[Scott Van Kalken]

Thanks guys.

Steven, I am familiar with Autosecure - it's now called Etrust - good product.

As for unix Shell access. We don't allow it, but what we do allow is NFS access via a novell NFS gateway.

...don't even ask....

I had to ask the question even if it sounds stupid. You never know I may have overlooked something.


Scott (getting annoyed at the fantastic solutions of other people where I work who know nothing about the basic concepts of computers).

[Patrick Wallek]

This is a good one for a basic lesson in file permissions.

The write permission on a file does NOT control whether or not the file can be deleted.

You can have a file with permissions of 666 (-rw-rw-rw-) so that users can modify the file, but still make it so the file can't be deleted. You do this by modifying the permissions on the DIRECTORY that the file is in.

If your file is in the directory /home/you and the file is yourfile then set /home/you to have permissions of 555 (-r-xr-xr-x) and no one will be able to delete the file, even if it has 666 (-rw-rw-rw-) permissions.

$ ll -d .
dr-xr-xr-x 5 z93573 other 1024 Feb 19 21:16 ./
[uran:z93573] 273 /home/wallek/wallek
$ ll testfile
-rw-rw-rw- 1 z93573 tty 12 Feb 19 21:16 testfile
[uran:z93573] 274 /home/wallek/wallek
$ rm testfile
rm: testfile not removed. Permission denied
[uran:z93573] 275 /home/wallek/wallek
$ id
uid=5028(z93573) gid=10(tty)

[Bill Hassell]

This is the most common misunderstanding of Unix permissiomns there is. The answer is: YES, you can prevent deletion of a file and still write to it.

Number one rule on permissions: The ability to delete a file has NOTHING (repeat, NOTHING) to do with the file's permissions! The existence of a file (creation OR deletion) is controlled by the directory!

Prove it with this scenario:

# touch /tmp/IamROOT
# chmod 000 /tmp/IamROOT

Now login as a dumb user. You cannot read or write this file even though it is in the /tmp directory. But try:

$ rm /tmp/IamROOT

Unless your sysadmin has set the sticky bit on the *directory*, the file is gone! You had no permissions to change the contents but removal is permitted by the directory. David Totsch (HP) put it best in a Unix Basics class:

"You do not have a complete understanding of the permissions on a file until you trace the directory path to where no-one has access to the parent directory."

In other words, not just the current directory but all parent directories--they all control the ability of a file to exist and/or to be seen.

So, set the sticky bit in shared directories (like /tmp and /var/tmp and files cannot be removed (or mv'ed) except by their owner, regardless of permissions on the file itself. No special software needed and it works on all flavors of Unix.

[Darrell Allen]

Hi Scott,

I see Patrick has beaten me to it. Yes, you can have write permissions on a file and not be allowed to delete it if you don't have write permissions on the directory in which it resides.

Just be sure the user doesn't own the directory else he could change permissions on it.

Darrell

[Deepak Extross]

Just playing the devil's advicate here, but the user can always zero out the file as long as he has write permissions:
cat >

Not quite the same as deleting the file, but what's a file without its contents?

Food for thought...

[Patrick Wallek]

Very true Deepak. But as long as users have write access to files, you are going to have that risk.

Also note that the 'sticky bit' that Bill refers to it the 't' permissions bit NOT the 's', which is the setuid, bit. See 'man chmod' for more information.

[federico_3]

You can use the sticky bit... a directory with the sticky bit set means that only the file owner and root may remove files from that directory. Other users are denied to remove files regardless of the directory permissions.


For more info go:

http://linux.oreillynet.com/pub/a/linux/lpt/22_06.html

Ciao
Federico