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] |
Ok, so then it does satisfy "Not be able to log into the machine and decrypt the password as a normal user"... right?
As far as the second one - not necessarily, although I will admit that I haven't actually tested such a thing myself. Externally identified means that the operating system (or third-party system) itself verifies the user validation, meaning that there must be a valid login on the database server. Also, there appears to be Oracle net support via Oracle Advanced Security. see here - there is also some information about identified globally, which allows for Active Directory verification.
| [reply] |
