sudoing adds a little bit of a roadblock to doing potentially stupid and dangerous things in the Linux shell, but it is a meager deterrent to newer Linux users. Still, many users login as root or have become desensitized to sudo, and may sometimes do bad things like:

  • chmod 777 /
  • rm -rf /
  • doh_oops > /dev/sda

It seems like there are few cases in which a user would really want to do these - their use is probably about 1% intentional and 99% accidental. Granted, it would be best to back up your systems and not do such dangeorus things - but newbies make mistakes, and Linux is unforgiving.

I'm not asking for UAC, but is there some sort of utility that can monitor console/SSH/other interactive sessions for command input and run it through some sort of validator before execution? A few regex rules could prevent a lot of pain, especially for newer Linux admins, and since most of the time you are not running a large number of commands from an interactive session, it would not be too much a hinderance. Ideally, the utility would generate an additional confirmation message - "are you SURE you want to go through with this, because it looks really stupid" - and require the admin to type in something acknowledging the danger beyond the standard "yes" so that he is forced to read it.

Does this type of utility exist? If so, I'd like to know where to get it.

If it doesn't, and it's a bad idea, please explain why.

  • 1
    Sooner or later you have to allow your sysadmins a degree of trust. Or get more trustworthy sysadmins. – Rob Moir Mar 20 '13 at 11:26
  • 1
    Actually, sudo does protect against your third example. That command will fail with Permission denied. The root privileges only apply to the process itself and not the shell you ran sudo from. – Ladadadada Mar 20 '13 at 11:33
  • 1
    @tacos_tacos_tacos: regex.info/blog/2006-09-15/247 – user9517 supports GoFundMonica Mar 20 '13 at 11:45
  • 1
    alias rm='rm -i' :D – nickgrim Mar 20 '13 at 12:47
  • 2
    I've always thought that unintentionally doing something horribly destructive is a rite of passage for every Unix/Linux sysadmin. It's how you learn the real importance of being careful :) – andytech Mar 20 '13 at 13:31

While I understand what you're trying to avoid and why you might want such a utility, consider the following: what do you do with dialog prompts that you expect? You quickly close/confirm them without giving additional consideration. Adding an expected "press Y to seriously run this command" will just be another "yes, I'm sure, dismiss."

Unfortunately, catching potentially dangerous or data destroying commands isn't as simple as a "few regex rules." To do this, you'd have to enumerate a rather thorough list of commands and combinations to guard against 'oopsies' (considering that each pipe, redirection, file copying, linking tool has data-loss/security implications).

As such, I don't know of an existing tool that accomplishes this. That said, maybe it's a great idea in which people would find great utility. If you do want to experiment with your idea, you could start by aliasing some "dangerous" commands to run after a "confirm wrapper."

To get you started with the scripting, check out this simple function that I hacked up for an automated installer: https://github.com/tristanfisher/culinary/blob/master/culinary.bash#L42-52

edit: I actually think this is a pretty cool idea, especially if it was available as a package that could be easily installed. Have a new Linux CLI user? apt-get install cli-seatbelt and add a line to his/her $SHELLrc. I wouldn't trust it to prevent my mom from accidentally firing off ICBMs via BASH, but entering a random 2 digit number could act as a "there may be dragons with running this command."

  • Yes, that was kind of what I was getting at. I know that many folks on here have no need for something that is going to offer them unnecessary advice, but for new bash users, Linux can be intimidating. They often do not realize that the training wheels are completely off. One thing I am wondering is how you would actually parse every command without modifying bash itself, but I am probably demonstrating my Linux ignornance – tacos_tacos_tacos Mar 20 '13 at 12:26
  • Oh, to do this smartly, you'd not parse every command -- that's a fool's errand as apt-get install whatever-new-command would be a miss in coverage. Instead, you'd tell that bash instance to pass commands through a wrapper script that checks if it should warn the user and then runs the original command unmodified. I feel like I'm not being clear, but this feels confusing without referring to a flow chart. Let's call such a wrapper/safety-script "seatbelt." The logic is basically: bash->seatbelt->ask user for confirmation->_only if user says yes_->execute command – 89c3b1b8-b1ae-11e6-b842-48d705 Mar 20 '13 at 12:36

I don't think a utility like this exists. I wouldn't say it's a bad idea but putting a crutch like this in place would leads to sloppy/ill advised practices that 'the system will catch for me'.

Not giving out root access, the correct use of sudo (not blindly giving everyone all:all) etc will go a long way to protecting you but there really is no substitute for competence when being a sysadmin.

  • It's quite hard to come up with a comprehensive list of 'bad things'
  • The same problem applies as UAC: people 'train' themselves to say yes without reading and thinking
  • It doesn't help you if you intend to do a 'bad' thing and it ends up with the wrong effect

Having said that, I think there are some things that could be done to make it better. A long time ago I had a kernel patch that force-killed any program that tried to delete a file called 'UNDELETABLE', and sprinkled files with that name in key directories.

There is also the capability system of SElinux. It's not easy to use, but I would have thought it was possible to make it require particular extra capabilities to change certain files or directories. Then 'root' isn't a fully privileged user unless you do something to acquire the extra capabilities.

Edit: Linux: Create files and direcotires but not delete them says "chattr +i" will render files immutable even by root.

  • I know SELinux is well suited to the task in some respects, but it is a) incompatible with a bunch of software (Oracle, I believe) b) really intimidating for new or inexperienced admins, c) annoying. – tacos_tacos_tacos Mar 20 '13 at 12:22

Pam filter is intended for this purpose. Its not really seen much development and may not do exactly what you want without adding code to do the filtering which it requires.


I should point out that even with something like this, dont underestimate the power of stupid people to do stupid things.

  • I have to admit, one of my motivations for asking was a colleague I knew briefly who had inadvertently dropped an entire Oracle database and then tried to hide that he had done so by deleting the log files. He didn't realize at the time that we had monitoring and that the log files were not just in one place. It turned out that he thought he was working on a dev database and messed up - it ended up being fine, but it would have been nice to know that someone was doing a drop tablespace including contents and datafiles on a production db server. – tacos_tacos_tacos Mar 20 '13 at 12:19
  • 1
    That's either a personnel issue or an environment issue. Everyone makes mistakes, always will, and we need accept and allow for that. Making a mistake is... well not fine... but understandable. The problem is trying to cover it up. Either that person is astonishingly unprofessional and should be fired or the environment they're working in has a terrible blame culture that looks to hammer people for being human rather than encourage people to be open about issues to fix them easier and to prevent a recurrence. – Rob Moir Mar 20 '13 at 12:43

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.