|
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 main 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 actions 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: -- //www.freelists.org/webpage/oracle-lOne solution you might consider is to store the password in another file that is read in by the setuid script. |
