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
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
Received on Sun Feb 19 2006 - 12:52:54 CST
