Question:
I have a problem where creating a new file with
utl_file.open creates improper permissions for the
file. When we run a
PL/SQL stored procedure that creates a file using
utl_file.open, the permissions are 644.
However, when the same stored procedure is
executed from inside an Oracle job, the resulting permission
from utl_file are 600. I check that the umask for the oracle
user is 022 so I would expect new files to have the default
permission of 622.
Why does the file permission change from 622 to 600 when the
utl_file is executed from a remote job?
Answer:
The file permission change from 622 to 600 when the
utl_file is executed from a remote job because of the value
of the default permission for the UNIX/Linux directory!
For example, if umask were un-set to a
value of 000 (wide-open), the default permissions for the
directory take over, and any new file would be created from
utl_file.open with permissions of 600.
When creating file in batch (as when you
called the PL/SQL procedure from a job), it’s not only the umask
that determines the final permissions for the new file!
There are three dimensions to creating a file from inside
a job:
You should check your directory inode
permissions to make all files within the directory where the
utl_file will create files has 664 permissions by default.
For example if you are writing to /home/oracle you can
issue the chmod command to change the default
permissions for new files in the directory:
chmod 664 /home/oracle
Then,
all files in that directory will be rw for the DBA
group (the middle octet).
