4

I know that root can do anything, but is there a way to at least alert root that they are about to delete a folder that perhaps shouldn't be deleted?

We keep a work directory in our /tmp folder, and from time to time an administrator will come along and purge the /tmp folder with roughly sudo rm -rf *. Is there a way to give something like a prompt or alert that they are about to delete a specific folder? Something along the lines of:

The folder XXXXX is protected from deletion - do you really want to delete this folder? (y/n)

I know, the best solution is to move this folder elsewhere (the /tmp folder is called temp for a reason after all!), but that has other problems. Hence my question.

Asking this question makes me wonder, is it bad practice to actually blindly delete all the contents of the /tmp folder? Isn't a better approach to only delete files that are more than a certain age?

Community
  • 1
Rich
  • 4,529
  • 2
    Why do you place something of any value into /tmp? On some systems, it's just a tmpfs living in the virtual memory. You could hardlink the important files into another directory, so they stay there even if removed from /tmp. – maaartinus Mar 01 '11 at 14:22
  • Maybe there can be better answers if everything think of it as a way to alert root when he tries to delete a certain folder (not necessarily in /tmp). I edited the title, hope that helps. – phunehehe Mar 01 '11 at 15:49
  • @maaartinus The data isn't exactly of value. I know I didn't say it in the question, but the data is purely the results of the previous run of some scripts so that the subsequent run can calculate a relative value based upon a previous run. If this data gets lost from time to time, the scripts are already written to not print data if they can't perform the comparison, and it doesn't matter if the scripts don't produce data once every 2 weeks - the scripts are run at least once every 5 minutes. – Rich Mar 10 '11 at 09:28
  • I see... but (from your other comment) it looks like you don't need the data themselves, you only need the directory to exist. I start all scripts by creating their destination directories (if applicable), since while testing I often remove them. I like my scripts to be as self-contained as possible. – maaartinus Mar 10 '11 at 09:49

3 Answers3

8

Moving your work folder is the solution. You're right that it is a little bit dangerous to wipe out files in /tmp blindly — normally, it's done either on system boot/shutdown or by using an access-time based deletion program (like tmpwatch). But by its definition, the space volatile and it's not reasonable to expect otherwise.

If you really want to prevent this, though, SE Linux could do it. You would give the directory a particular label, and configure it so that root doesn't normally have the unlink permission for objects with that label. This seems like significantly more work than just moving the directory to a better shared location, though — and since it causes an SE Linux audit message rather than the nice "are you sure y/n" prompt you're imagining, it seems like it'll eventually cause frustrating confusion.

mattdm
  • 40,245
  • 1
    "Frustrating confusion" being the hallmark of SE Linux in general. *sigh* – mattdm Mar 01 '11 at 14:41
  • I have accepted your answer as it is the best solution in the context of the question. However, in the end we decided to recreate the directory at the beginning of the scripts that rely on it. mkdir -p /tmp/workfolder – Rich Mar 10 '11 at 09:26
3

You could change the directory attributes on the directory to be immutable:

# cd /tmp
# mkdir undeletable
# chattr +i undeletable
# rm -rf undeletable/
rm: cannot remove `undeletable': Operation not permitted

Unfortunately, since the directory is immutable, you can't modify it either:

# cd undeletable/
# touch foo
touch: cannot touch `foo': Permission denied

You can have subdirectories that are mutable, but rm -rf will delete the files still. So this solution will only work if you want read-only content in /tmp.

If you must have RW content in /tmp that's undeletable, why don't you just put it somewhere else more permanent, and create a symlink in /tmp, that can be easily restored. (perhaps automatically if missing?)

jsbillings
  • 24,406
-3

chmod +t /tmp/perm_file

source: http://oldfield.wattle.id.au/luv/permissions.html

Philluminati
  • 124
  • I've just tried this and it doesn't work, sadly. – Rich Mar 01 '11 at 14:34
  • 1
    Yeah, it's completely wrong. This will keep unprivileged (i.e., not-root) users from removing files they don't own from the directory even if they have write access to the directory yourself. (For example, /tmp itself is usually set this way.) It doesn't stop root from anything. (And in fact, it doesn't even protect the directory itself from non-root users who have write access to the directory's parent.) – mattdm Mar 01 '11 at 14:40