1

I have a script that checks for the presence of a file, and if it exists, read a list of email addresses from it to send notifications. When I don't need to be notified, for instance, when I'm at work already monitoring the output, I'll rename it. I just don't want other admins to possibly delete it.

I know chattr +i will make the file immutable, but I only want to prevent the file from being deleted. I figure the chattr program would be using the inode number to track attributes and not the file name.

Is there a utility that can make this happen?

|improve this question
  • If any of the existing answers solves your problem, please consider accepting it via the checkmark. Thank you! – Jeff Schaller♦ Apr 25 '17 at 10:39
2

That comment about "other admins" hints that you have root privilege on the system where you want to store the file. Anything that you could setup in the way of permissions could be undone by someone with the same privileges.

If that is not a concern, and no one has extended privileges, then you could simply put the file in /tmp or /var/tmp, which usually have the t-bit set (preventing other nonprivileged users from deleting it. You can chmod the file to make it group-writable (and modifiable by others in the same group).

|improve this answer
  • Isn't there usually a cron job or something that periodically cleans out old files in /tmp? It would have to do so as root, wouldn't it? Better to put it in its own directory somewhere else, I think. – Tom Zych Nov 7 '15 at 9:53
  • Some systems clean /tmp on startup (Debian for instance), some do not (for instance Fedora). Now that you mention it, some of OP's questions are tagged /lubuntu. With Debian (basis for Ubuntu), /var/tmp is ignored, but /tmp is cleaned. – Thomas Dickey Nov 7 '15 at 10:25
  • You can set the sticky bit on any directory you want. – jthill Nov 8 '15 at 19:22
  • Same issue: it makes no difference to "other admins" if they have extended privileges, and is irrelevant otherwise. – Thomas Dickey Nov 8 '15 at 19:26
2

Are the "other admins" malicious?  Are they out to get you?  If yes, there's probably nothing you can do.

If not, perhaps the simplest solution is to change the script to put the file in your home directory.  A variation on this is to make hard link(s) to the file in different director(ies); as long as they don't delete (unlink) all the links, the file will still be intact.  (You should write another script to go through all the link locations, find one that still exists, and then re-link all the one(s) that have been removed.)  Beware that some editors break links (i.e., if you edit the file).

This might solve the problem even if the "other admins" are malicious and/or out to get you, if they are inexperienced and not thorough.

Or make the file immutable, and change the script to use some other test to determine whether to send the emails.

|improve this answer
  • Not malicious, just not as experienced as I am with the scripting. I don't need to make it impossible to delete the file, just harder than accidentally doing it. – user208145 Nov 7 '15 at 3:59
  • 1
    @user38537: If you have fellow admins accidentally deleting files, you have bigger problems than this :) – Tom Zych Nov 7 '15 at 9:54
1

To the point raised in some of the other answers, you could use the mv utility to suggest a social barrier:

mv yourfile THIS_IS_user38537_FILE_PLEASE_DO_NOT_REMOVE
|improve this answer
  • And/or, depending on the exact mindset and skill set of these non-malicious, inexperienced admins, rename it to a name containing special characters (such as space, tab, $, and/or possibly non-printing control characters), so they might not know how to delete it.  Specifically, if it begins with such a character, autocomplete might not work.  Or rename it to -i or -- and laugh as they try to rm it.  Of course, if they can't figure out how to overcome these simple hurdles, ISTM that they aren't qualified to be admins in the first place (but now I'm getting out of scope). – G-Man Says 'Reinstate Monica' Nov 8 '15 at 18:42
1

[Replacement for old answer]

You could simply make a hard link to the file:

ln email_file hard_link

Then, if it's deleted, it still exists and can easily be restored.

[Old answer, based on misunderstanding of the problem]

One solution would be to make the script itself immutable with chattr, but turn it on and off, not by renaming it, but with the presence or absence of an empty file that you can afford to lose. Call it, say, snoozebutton. If it exists, the script doesn't notify. If it's not there, the script does notify. Doing it that way fails safe if someone accidentally deletes it: you get your notifications, and you're also notified that something happened to snoozebutton.

This assumes that you don't need to modify the script often, of course. If you do, you'll want a little utility script to run chattr, then run the editor, then run chattr to lock it again.

|improve this answer
  • The OP doesn't seem to be concerned about the script itself being deleted (although we don't know why not).  But, if we change your answer to say "make the file (the list of email addresses) immutable with chattr, and change the script to turn the email function on and off, not by renaming the file, but with the presence or absence of an empty file [a different file] that you can afford to lose ...", it becomes a more detailed version of the last sentence of my answer. – G-Man Says 'Reinstate Monica' Nov 8 '15 at 18:21
  • @G-Man: Huh. For some reason I thought they were trying to save the script from being deleted. Misread. I have another idea that I will replace this one with. Thanks. – Tom Zych Nov 8 '15 at 18:28

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.