Re: Allowing users to execute shell scripts without seeing password

  • From: Joseph Amalraj <joseph@xxxxxxxxxxxxxx>
  • To: m.haddon@xxxxxxxxxxx
  • Date: Sun, 19 Feb 2006 06:10:34 -0800 (PST)

Thanks was making me aware of the capabilities of Perl.
  Had tried to use, trap command,  but users in the system always got around it 
in the long run. The solution, that I had to implement was to use the shell 
script name in /etc/passwd file instead of the name of the shell. 
  Interpretive languages need to read the script and thereby need a read 
privilege on the file. Compiled languages could also have the same 
deficiencies, if some-one tried to debug a core dump file.
  Main problem is with password being stored in files. How can scripts/programs 
run by some other user (other than owner) utilize this password, without 
actually being able to see it. Basically, this boils down to sharing a password.
  One solution for this could be that every user, who runs the script/program 
should have his own password. I have liked Oracle os authenication not "remote 
os authent'. but this can be only used if the database is local.
Michael Haddon <m.haddon@xxxxxxxxxxx> wrote:
  There is nothing Magic about perl that would solve the security issues that 
come up when using a 'setuid' bit on the executible. The setuid capability is a 
Unix capability and not one specific to the shell. A setuid script has it's 
risks if it is written in perl, ksh, bash, awk, tck/tkl, or whatever. It just 
needs to handle any security issues, if they exist, in the code.

Most scripts really don't need the setuid bit, those that do, can use the 
'trap' in the shell to handle any post signal processing. One example of this 
can be found in the /etc/profile script that is executed by everyone that logs 
into a Unix system. Part of the login process executes this script to set up a 
system wide default environment.

The beginning of the script uses the trap command to set up signals that need 
to be handled and the end of the script releases the trap.

My point is that sometimes the setuid bit can help accomplish a task that would 
otherwise take some considerable time to design and code. You just have to be 
aware of it's use and test it thoroughly.

Hope this helps

Mladen Gogala wrote:   
On 02/18/2006 11:38:01 PM, Joseph Amalraj wrote:    
After doing some reading, I agree, that setting suid for shell scripts is poses 
  security risks. Probably the solution is not to use Shell, but some else like 

  So, if switching UID is dangerous with a shell script, it will somehow be   
rendered harmless if you use Perl, which allows all kinds of programming   
tricks and hacks?        

Other related posts: