SUMMARY: perl, oracle, sendmail and Solaris 10

Thank you to all who sent responses.  Vladimir Terziev pointed out an
oracle bug 4516865 that implies a problem with permissions for
everything under ORACLE_HOME.  A few other people suggested that
changing the permissions on the ORACLE_HOME files to 755 shouldn't be a
problem.

After discussing with our Oracle admins, we decided that since Oracle
made the file permissions more restrictive for security, and their
install directions say to only run the changePerm.sh script if you have
to, that we would just determine which files or directories need to have
more permissive rights for what we are doing, and only change the
permissions on those.

Thanks again.
Nicole

-----Original Message-----
Hello,



We have a perl (v 5.8.4) script that gets executed when users send email
to an email alias on a Solaris 10 machine.   This script uses Oracle
modules (dbd-oracle 1.19) to access an Oracle 10 database.  We are
having problems getting this script to work with the alias.

The user who I'm helping said that the script ran ok as root from the
command line, but not with the alias.



The alias for it in /etc/aliases is as follows:

eg: "|/apps/syrApps/egate/bin/eg.pl"



To test, I did a truss on the sendmail process and the processes it
forks, and sent email to the alias.  Right after the call to the
DBD:Oracle module, I saw an error "

Err#13 EACCES [file_dac_search]" for the files
/apps/oracle/product/10.2.0/lib/libclntsh.so.10.1 and
/apps/oracle/product/10.2.0/lib32/libclntsh.so.10.1.



The "file_dac_search" indicates a permission problem. Both of these lib
directories have permissions 750.  So, I temporarily changed
/apps/oracle/product/10.2.0/lib/ to 755, ran another test, and saw
different output for that call in truss, but still an error for the
lib32 directory.  If we change the permissions of all of the files in
the the Oracle client install directory to 775, sending email to the
alias works.



Obviously that is not a good solution. I tried putting the sendmail
"smmsp" user in the "oinstall" group, but that did not help. I think the
problem might have to do with the Solaris 10 principle of least
privileges or role based access control, but I'm not sure. I just
started reading about these and am not familiar with them.



Does anyone have any suggestions on how to fix this?



Thanks,

Nicole
_______________________________________________
sunmanagers mailing list
sunmanagers@sunmanagers.org
http://www.sunmanagers.org/mailman/listinfo/sunmanagers
_______________________________________________
sunmanagers mailing list
sunmanagers@sunmanagers.org
http://www.sunmanagers.org/mailman/listinfo/sunmanagers