Re: how to determine the osuser of a session

Billy schrieb am 21.06.2005 in
<1119338901.234266.179680_at_f14g2000cwb.googlegroups.com>:

> Andreas Mosmann wrote:

>> It would be easier to handle, if such a record also contains the osuser
>> or the terminal he sits on, so that you differentiate between the users
>> (in our case we implemented an own user management, so that "SELECT
>> userid FROM DUAL" is useless).

> Well, irrespective of how you implement your application security
> model, the app establishes a client session with Oracle.

>> From an Oracle instance perspective, all that you have in that regard

> OSUSER VARCHAR2(30) Operating system client user name
> PROCESS VARCHAR2(12) Operating system client process ID
> MACHINE VARCHAR2(64) Operating system machine name
> TERMINAL VARCHAR2(30) Operating system terminal name
> PROGRAM VARCHAR2(48) Operating system program name
this I know, but which is the session that the program is using?

> The client's IP address:
> SQL> select SYS_CONTEXT('USERENV','IP_ADDRESS') from dual;
This helped a lot, so I can search SYS_CONTEXT, (OS_USER works too)

>> From V$PROCESS, the process id of the client application - e.g.


> thread/process handle of a Windows client:

> SPID 	VARCHAR2(12) 	Operating system process identifier

> You can dig around the Oracle Reference Guide for additional details
> about the client. But what is listed in this guide is all that is
> essentially there from an Oracle server perspective.
This is enough, I looked for an entry point

> Also keep in mind that much of this detailed is supplied via the client
> driver used by the client session - e.g. JDBC drivers may not always
> provide the same info as OCI drivers. And as this is from the client,
> it can be spoofed by the client. So none of this data is to be trusted
> - which makes it essentially useless for security or FGAC, and puts a
> questionmark over just how valid this data is when getting into the
> legal side of auditing.

This is not my problem and not a solution, because: - there is only 1 program that uses the database, and this is written by us using direct oracle connection (without client) that gives the information I look for
- it is only a debug- tool, that tells me what happens with the program. The database itself doesn't know anything about program so you can not use auditing functions. In the final application only (program)errors will be logged.

Thank you
> --
> Billy

Andreas

-- 
wenn email, dann AndreasMosmann <bei> web <punkt> de