Beefy Boxes and Bandwidth Generously Provided by pair Networks DiBona
more useful options
 
PerlMonks  

Re^4: DBI Password connection to Oracle

by waswas-fng (Curate)
on Jun 28, 2005 at 17:44 UTC ( #470733=note: print w/ replies, xml ) Need Help??


in reply to Re^3: DBI Password connection to Oracle
in thread DBI Password connection to Oracle

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.



-Waswas


Comment on Re^4: DBI Password connection to Oracle
Re^5: DBI Password connection to Oracle
by Transient (Hermit) on Jun 28, 2005 at 17:54 UTC
    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.
      Ok, so then it does satisfy "Not be able to log into the machine and decrypt the password as a normal user"... right?

      Nope. If you use a unix account for verification, you need to have the password working (and you need to pass the user and password from the perl script). The system service accounts such as nobody don't have a working password and therefor are unusable, the normal user accounts have working passwords, but have access to loginto the system (as implied from the OP) and therefor would have access to both their user:pass and the systems user:pass database (indirectly).

      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.

      I understand what you are showing here, although because of the overlapping requirements in the OP, it makes anything which actually uses a user and password combo not usable. the External User functions in oracle are basically back end hooks for OS, Net, or OSA auth types instead of database user:pass -- the connecting client still needs to send off the user and password, and to do so logically must have a user and password available to it (which is not allowed in the restrictions in the OP). The way the requirements overlap it makes it almost impossible to use DBI in any form. I have asked for more clerification in my other thread, if the OP comes back and gives more info that may open up another solution.


      -Waswas
        If you use a unix account for verification, you need to have the password working (and you need to pass the user and password from the perl script).
        Not so... in fact, that's the point of "identified externally". "With external authentication, your database relies on the underlying operating system or network authentication service to restrict access to database accounts. A database password is not used for this type of login." reference

        The system service accounts such as nobody don't have a working password and therefor are unusable, the normal user accounts have working passwords, but have access to loginto the system (as implied from the OP) and therefor would have access to both their user:pass and the systems user:pass database (indirectly).
        That I'm not sure of - whether or not it would validate that 'nobody' was logged in and pass that through or not... worth a try though. But again, you are not passing the UNIX password - since the user is already logged in, it's using UNIX's authentication of the user itself.

        Going back to the ssh example (and this ties into your second point) - the use of public/private challenge and response keys exhibit a way to verify login over a network without passing unencrypted sensitive data. But all of this needs to be tested and it depends on what type of UNIX the OP is using, as well as the type of Oracle.

Log In?
Username:
Password:

What's my password?
Create A New User
Node Status?
node history
Node Type: note [id://470733]
help
Chatterbox?
and the web crawler heard nothing...

How do I use this? | Other CB clients
Other Users?
Others pondering the Monastery: (5)
As of 2014-04-19 21:07 GMT
Sections?
Information?
Find Nodes?
Leftovers?
    Voting Booth?

    April first is:







    Results (483 votes), past polls