Re: Allowing users to execute shell scripts without seeing password

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_at_comcast.net> 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_at_comcast.net> 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

--

http://www.freelists.org/webpage/oracle-l

• http://www.freelists.org/webpage/oracle-l

--
http://www.freelists.org/webpage/oracle-l