/var/logs drwxr-x--- bob admin
/var/logs/bob drwxrwx--- bob admin
I have /var/logs/bob in my INIT.ORA file.
I have made oracle a member of the admin group.
I write a log file 'test.log' into /var/logs/bob successfully when I am
logged into both Unix AND Oracle as bob.
It creates a file like
/var/logs/bob/test.log -rw-r--r-- oracle oinstall
This means that a process owned by oracle has created the file 'test.log'.
The problem is that I cannot get other users to write to this log file... I
don't want to put them all in the admin group - I just want to log their
calls to several stored procedures.
Any help appreciated.
"Christopher Burke" <cra...@hotmail.com> schrieb im Newsbeitrag
news:90257F33...@130.102.2.1...
> I have a directory /var/logs/bob
>
> /var/logs drwxr-x--- bob admin
> /var/logs/bob drwxrwx--- bob admin
>
> I have /var/logs/bob in my INIT.ORA file.
>
> I have made oracle a member of the admin group.
>
> I write a log file 'test.log' into /var/logs/bob successfully when I am
> logged into both Unix AND Oracle as bob.
>
> It creates a file like
>
> /var/logs/bob/test.log -rw-r--r-- oracle oinstall
>
> This means that a process owned by oracle has created the file 'test.log'.
This is the usual behaviour of the system: The UTL_FILE functions - most
interesting: the file access on Unix - are executed by the database
processes owned by the Unix(!) user which started the database (usually
named "oracle"). The name of the Oracle(!) user calling the UTL_FILE
functions does not matter. As I know all Oracle users writing and reading
files via UTL_FILE have the same access rights. If one can read or write
it - all can read or write it.
> The problem is that I cannot get other users to write to this log file...
I
> don't want to put them all in the admin group - I just want to log their
> calls to several stored procedures.
So, this should not be a problem. (Did you try it?) The problems may begin
as you want several Unix users to access the file. Then you have to check
the "umask" of the Unix user "oracle".
May be I am wrong, but I think your failure is to mix the meaning of users
on Oracle and users on Unix. They are independend from each other - even if
you give them the same names.
regards
Holger Kreft
This may not help in your case, but there are two ways that I get around
this problem. The first solution is to "pre-create" an empty file with
the correct name in the specified directory and make sure that it has
the required permissions. Then instead of opening the file for "W" I
open it with "A" and then write records to it.
The second solution is to send output to dbms_pipe instead of utl_file
and then have a separate listener process do the file i/o. It takes more
programming but in some cases it makes for a more flexible approach.
>Hi Christopher,
>This is the usual behaviour of the system: The UTL_FILE functions - most
>interesting: the file access on Unix - are executed by the database
>processes owned by the Unix(!) user which started the database (usually
>named "oracle"). The name of the Oracle(!) user calling the UTL_FILE
>functions does not matter. As I know all Oracle users writing and
>reading files via UTL_FILE have the same access rights. If one can read
>or write it - all can read or write it.
The problem is that the name of the user logged into the OS AND Oracle DOES
matter. That is the file is created as oracle/oinstall - but if user 'bob'
can't access the directory he cannot write to the file. Even thow oracle has
write access to the directory and file.
>> The problem is that I cannot get other users to write to this log
>> file...
>I
>> don't want to put them all in the admin group - I just want to log
>> their calls to several stored procedures.
>
>So, this should not be a problem. (Did you try it?) The problems may
>begin as you want several Unix users to access the file. Then you have
>to check the "umask" of the Unix user "oracle".
Thats all fine - oracle as a user has no problem, but the users logging into
oracle seem to also need write permissions to the directory/file, thats what I
want to remove.
>May be I am wrong, but I think your failure is to mix the meaning of
>users on Oracle and users on Unix. They are independend from each other
>- even if you give them the same names.
users on Oracle == users on Unix as they all use 'external' Authentication,
which mean unix user BOB logs in as Oracle user BOB.
>
>regards
>
>Holger Kreft
>
>
>