One solution you might consider is to store the password in another
file that is read in by the setuid script. As the user executes the
script, which he/she has read permissions on, the script can read an
encrypted/plain text file that is only readable by the owner.
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.
Regards
Joseph
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
Mike
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 Perl.
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?
-- http://www.freelists.org/webpage/oracle-l
