Path: utzoo!attcan!uunet!know!sdd.hp.com!wuarchive!rice!uupsi!sunic!isgate!krafla!heimir From: heimir@rhi.hi.is (Heimir Thor Sverrisson) Newsgroups: comp.databases Subject: Re: Using auto-login feature of Oracle Message-ID: <2524@krafla.rhi.hi.is> Date: 11 Dec 90 15:19:27 GMT References: <911@attc.UUCP> <143900010@occrsh.ATT.COM> Organization: University of Iceland Lines: 38 In <143900010@occrsh.ATT.COM> srm@occrsh.ATT.COM writes: [deleted stuff abt. "CONNECT /" failing over network] >turns out that "CONNECT /" causes the background oracle process to go to >the operating system for info on your user id. No problem yet. When >you attempt to connect through the network, the background oracle process >must do the same thing (as before) __ONLY__ on the remote machine. It does not do that properly and that can only be regarded as a BUG! [deleted bug speculation] >only work-around to this problem (that I and Oracle have found) is to >connect via the following: > CONNECT OPS$USERNAME/PASSWORD@T:machine_name:SID >This will work although PASSWORD will have to be in source code. >This creates a security problem! But it does work. This is one more addition to the "Oracle security joke under Unix". The first part I came across was that user could run a utility from the command line with his/hers username/password as an argument! Not only can a person looking over his shoulder see it as it is typed, but everyone taking a long list of the processes ('ps axu'/'ps -ef') can get easy access to Oracle. With this workaround, somebody with read-access to the program sources can get some passwords with 'grep -i connect *.c'!!! The worst part of this big security joke is that you cannot even turn this useless system off, and it's getting in the way of users all the time! >-- >Steven R. McMaster UNIX(R) mail: ...!uunet!att!occrsh!srm >AT&T Network Systems >Oklahoma City Works Any opinions expressed in the message above are >srm@occrsh.att.com mine, and not necessarily AT&T's. -- Heimir Thor Sverrisson heimir@rhi.hi.is