I do not know that your solution meets the Not be able to log into the machine and decrypt the password as a normal user. or Not be able to get the password into a variable in perl. requirements.
| [reply] |
Well, as far as the first one goes, it's impossible if the "normal user" is the same as "nobody" or whatever the CGI/Perl user is. If that user can't 'read' the password file, it's a lost cause, period.
The second one has nothing to do with "identified externally". It should use the UNIX user id/password to validate the user (without the need to pass the actual password). This may or may not work across a network depending upon the flavor of *NIX and type of Oracle. However, remote login via ssh is available without passing a password using public/private key encryption, so I'd figure something similar would be possible here (although I'm not 100% on that).
| [reply] |
nobody or other service users on unix generally have password set to NP or some other special string that does not actually work as a password for the system. This in effect locks out standard auth on the user and only allows su - actions from root.
The second one as I read it means that DBI access is out of the question -- It either means that his script cant hold the auth keys (no auth at all) or that the auth should be in a form that is not usable in perl.
| [reply] |
