Re: Allowing users to execute shell scripts without seeing password
- From: Joseph Amalraj <joseph@xxxxxxxxxxxxxx>
- To: Michael Haddon <m.haddon@xxxxxxxxxxx>, joseph@xxxxxxxxxxxxxx
- Date: Mon, 20 Feb 2006 06:22:36 -0800 (PST)
Hi Michael,
What if the user enters a break or quit before the trap command.
In one of the previous jobs, there were more than a 1000 users, I had set
trap command at the begining of the .profile.
Still they used to manage to get to the "$" prompt.
Regards
Joseph
Michael Haddon <m.haddon@xxxxxxxxxxx> wrote:
There isn't anything wrong with putting it into the password file, it is just
another way to do it. However, the capability to do this in the password file
wasn't designed to be used for that purpose
The /etc/profile has the trap command to prevent ^C from effectively halting
the the script while it is being executed.
Mike
Joseph Amalraj wrote: Hi,
Please let me know what is the issue with putting the script name in the
/etc/passwd, other than it being cumbersome.
In this case the script does not need setuid bit.
Even while executing /etc/profile, what would happen if the user pressed "^C"
or quit, before executing the relevent portion of the /etc/profile. In this
case, the user has access to unix shell prompt.
Joseph
Michael Haddon <m.haddon@xxxxxxxxxxx> wrote:
It's not really. My point was that there are alot of ways to do this.
From what I understand, the problem is to allow Unix accounts to log into a
Unix server that may or may not be running an Oracle server. Once this log in
is successfull the user is to be taken straight into SQL*Plus using the ma in
schema name/password and there are concerns about the login script needing a
privileged password to get access and having to be readable by whomever is
executing it.
There are really a hundred ways to do this. The suggestion below doesn't solve
anything. If I had to accomplish this I wouldn't do it by replacing the shell
command in the password file, or by using a setuid script. What I would do is
call the script from the /etc/profile. Maybe put some code in the script ,
(/etc/profile), to control which Unix accounts call it.
Either way - there are more concerns than just the setuid. You have to make
sure the user cannot bang out of SQL if you don't want them to access the Unix
OS.
The main point is that there is probably a better way - This just depends on
what you want to accomplish. If the users are continually snooping for ways to
get around the controls then you have your work cut out for you. Sometimes I
find it much easier to record a ctions and publish policy about acceptable uses
of the system and make sure you follow up when users attempt to do something
they're not supposed to. Almost every time I see something that is not supposed
to be done I can prevent it by just informaing the specific user that you know
and let him understand the problems he/she can bring upon themselves.
You can either lock them down with large fences, or put up some small fences
and make sure they see the big dog on the other side of it.
Mike
Radoulov, Dimitre wrote: 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.
May be I'm missing something but how this case diffe rs from the previous
solution: script with setuid without read access?
Regards,
Dimitre
--
//www.freelists.org/webpage/oracle-l
-- //www.freelists.org/webpage/oracle-l
Other related posts:
