Disable ability to run a shell script

[Don Bentz]

aside from the obvious permissions solution for individual script files, is there a way to simply prevent persons outside a given group from executing a script from the command line? I realize that there are many programs (ll, cp, mv) that need to be utilized by just about anybody on the system, but I am trying to find a way to secure certain shell scripts. We would like to be able to keep people (i.e., developers) from "launching" a production script in a similar fashion as other environments (i.e., IBM Mainframes).

[Rodney Hills]

At our site production users are a member of one group, and developers another. Then the production files only have group write access to the production users. A developer is not able to directly update the production data files.

HTH

-- Rod Hills

[Biswajit Tripathy]

You could add few lines at the beginning of the
script to decide. Something like:

grp_id=$(id -g)
# Assuming 20 is the group id of the group
# you want to give execute permission
if [ $grp_id -ne 20 ]
then
echo "Sorry, no permission"
fi

- Biswajit

[Don Bentz]

Actually what I am referring to has to do with maintaining a legitimate "change control" method, i.e., the developer "logs out" a program, makes modifications and then has the "production group" move it back to production. I'm not sure what I can do to prevent the developer, after having made those modifications from "submitting" this script.

[TwoProc]

I can think of three ways:
A) permissions to the file
B) Check permisssions in the program itself - like the previous posting. I like this one, and if you add in some trap statements, it works well.
C) Create a new user that can run the selected processes - and give access to these commands via sudo. I've used this on too, and like it for secure processes.

[Bill Hassell · Accepted solution]

What you're describing is the classic sourcecode control system and this cannot be solved with permissions. You need a reference library where code is checked-out and checked-in, along with tracked code changes (what and by whom). The classic (but tedious) Unix method is SCCS (man sccs) but I suspect that developers may not always play by the rules (that's already apparent). I assume that the production servers are immune from casual developer changes (they are, right???). If development occurs on the same machine, perhaps it would be interesting to develop a cost associated with mistakes due to lack of sourcecode controls. Then look at some commercial solutions.

[Don Bentz]

Well, that's what I wanted to know, or more correctly, what I suspected. Thanks, everybody.

[Don Bentz]

Whoops, thanks again.