Thanks for all the answers. I'm still somewhat in the fog.

The installation owner is 'oracle'. User A is a different user.
And still I would like to know how the internals work. Do the oracle server
processes really do a setuid and setgid and run in the (security) context of
the Unix user that started the action (e.g SQLPLUS) ? That would mean, that
I can be correctly authenticated to
Oracle and still not see data that I'm supposed to see (this situation).
What about remote access with ODBC/Listener/Server Process ?

BTW: User A is in the dba group and user B isn't.

Thanks for enligthening me,

/Gerold

"Gerold Krommer" <g.krommer@doremove.fns.co.at> schrieb im Newsbeitrag
news:at537n$5u1$1@at-vie-newsmaster01.nextra.at...
> Sorry for the repeat. I have browsed google and found a few entries, but
non
> were really satisfying. My Oracle knowledge is (let's say) moderate.
>
> The problem:
> Oracle 8.0.6, Solaris 2.6, but I m pretty sure I have seen this on older
> versions and other platforms, too (e.g. Oracle 8.1.7 and HPUX 11i).
>
> We are able to access the database with e.g. SQLPLUS when logged on as
Unix
> user A, but not as User B.
>
> The error is:
> QL*Plus: Release 8.0.6.0.0 - Production on Tue Dec 10 15:13:55 2002
> (c) Copyright 1999 Oracle Corporation. All rights reserved.
> ERROR:
> ORA-00604: error occurred at recursive SQL level 1
> ORA-01115: IO error reading block from file 1 (block # 1122)
> ORA-01110: data file 1: '/fnsw/dev/1/oracle_sys0'
> ORA-27041: unable to open file
> SVR4 Error: 13: Permission denied
> Additional information: 3
>
> First I have a problem understanding why the Unix user matters. Isn't it,
> that only the Oracle processes access the data files ? So I only need to
> authenticate to Oracle by logging on.
>
> Second, my research on google has shown that certain protections on
certain
> files must be set, but this information was really dispersed over several
> notes entries. Is there a place where there is a concise description on
what
> must be set to what (e.g.SUID bit, etc.)
>
> Thanks very much,
>
> /Gerold (g.krommer@doremove.fns.co.at)
>
>