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:
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 differs 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
Received on Sun Feb 19 2006 - 10:27:06 CST
