UNIX for Advanced & Expert Users

When invoking unix commands from other third party tools (IBM ETL), we run the rm / mv commands with the folder as argument been passed. Eg

Code:

rm -rf {folder}/*

when the parameter {folder} did not pass rightly or becomes blank, the command becomes dangerous to execute

Code:

rm -rf /*

How to prevent the disaster?

I seen some suggestions to add alias as alias But this wont work all the time, as we cannot make the command interactive when running from a tool.

Situation becomes worse, when the command is execute via super user.

Please throw some light.

Thanks,
Deepak

Let me see if I understand what you're doing. You have a script that is given an operand that is the name of the directory to be removed. You expect it to be invoked with something like:

Code:

removeall drectory

and you have written removeall to be:

Code:

#!/bin/YourShellName
rm -rf "$1"/*

And, if the person who invokes removeall forgets to give an operand, bad things happen.

So, why did your script add /*??? If the script had been:

Code:

#!/bin/YourShellName
rm -rf "$1"

you would get the same results when a directory operand is given, but you wouldn't have a problem when no operand is given (rm would just print a diagnostic saying no operands were given or an empty string is not a valid pathname).

Or your script could actually check for missing or "invalid" operands:

Code:

#!/bin/YourShellName
IAm=${0##*/}
if [ $# -ne 1 ] || [ ! -d "$1" ]
then    printf "Usage: %s directory\n" "$IAm" >&2
        exit 1
fi
rm -rf "$1"

UNIX utilities are there to help you get a job done. If you use them correctly, they can do wonderful things for you. If you tell them to do stupid things, you'll get what you asked for.

One way would be alias rm to a script that checks its parameters:

Code:

alias rm='/usr/local/bin/myrm.sh'

Code:

#!/bin/bash
# script: myrm.sh
# check parameters to prevent system damage

[ "$*" = "-rf $(echo /*)" ] && echo "Illegal parameters" && exit 1

/bin/rm $@

Edit: as Don Cragun was faster I'll explain how I interpreted the OP: his problem is invoking commands via a third party tool which does not check the parameters it passes.

This is an extremely dangerous script. It seems to be intended to catch an attempt to remove all files in and under the root directory. But,it won't complain if you try any of the following (all of which do exactly what this script seems to be intended to catch):

Code:

rm -r -f /*
rm -f -r /*
rm -fr /*
cd /; rm -rf *
rm -rf /

It won't complain if there happen to be any files in the root directory that contain a tab character, start or end with a space character, or contain two or more adjacent space characters. It will fail if any file is added to or removed from the root directory between the time when the rm alias was called and the time when this script processes echo. And, it will attempt to remove a different set of files than what was requested if any files in the operand list contain any whitespace characters.

That's why I explained how I interpreted the original post, but you're right, I was not clear enough.
I assumed that the third party tool issues rm -rf /* if the user of that tool does not provide any arguments. ONLY this case is catched. The user of that tool may not have any knowledge that he is working on an UNIX system at all because he only sees that tools frontend and may not know what effect is caused by not giving any arguments.
For all other cases I'll quote you: A user who issues the commands you mentioned in the last reply most likely knows what he is doing - that would not be an accidental use of the rm command.

Edit again: thanks for pointing out the issues in your last paragraph.
In my tests (using GNU bash, version 4.1.5(1)-release (x86_64-pc-linux-gnu)) the script compains correctly when there are files in the root directory that contain space or tab characters in their names.
I'm not sure if the race condition can be entirely avoided (given my assumtions about the problem are correct).
The issue with whitespaces in the operand list is caused by my lack of quoting. The last line should read /bin/rm "$@".

Don / Cero, Thanks for your Reply!!!

I was intended to say as what Cero interpreted.
The tool that I use, would invoke a "rm" or "/usr/bin/rm" commands.
Operands will be passed to the 'rm' utility, with the optional arguments of -r / -rf / -f etc as parameters.
Eg for the parameters:

Code:

/usr/bin/rm -rf #folder#/#filepatter#*.csv

rm -f #folder#/#filepatter#*

/bin/rm -rf #folder#/*

cd #directory# ; touch #file(s)# ; rm -rf #file(s)#

During any abnormality, there are chances for the tool to send parameters like #folder# or #file# as empty value.
And we know the impact of it.

I was infact trying the options this morning, similar to what cero was describing in.
I created the alias, and it would work in unix terminal, but not in the tool. Not sure, If i need to bounce the tool to refresh the change in .profile.
So with the help of admins, i tried to create the soft link for the rm command.
/usr/bin

Code:

rm -> /home/dsadm/rm_chck.ksh

And it seems to work for my testing.

And thinking to add more conditions to capture in the script as Don mentioned.

Atleast this way, we can avoid the possibilities of known issues that we far. Hope this would be a right way to proceed.

Aliases only work for interactive users.

This does not mean you should gut and replace your rm command with a script -- that'd be a very bad idea, important system things may use rm.

It means you should fix your tool instead. Adding more conditions would be a good idea.

Is there any possibility for editing the tool itself, or are you stuck with it?