oerr problem in oracle 12c.

[Mladen Gogala]

I tried to do oerr from a non-oracle account, with the following result:


oerr ora 257
Can't locate English.pm in @INC (@INC contains: /oracle/product/12.1.0.1/
dbhome1/perl/lib/site_perl/5.14.1/x86_64-linux-thread-multi /oracle/
product/12.1.0.1/dbhome1/perl/lib/site_perl/5.14.1 /oracle/
product/12.1.0.1/dbhome1/perl/lib/5.14.1/x86_64-linux-thread-multi /
oracle/product/12.1.0.1/dbhome1/perl/lib/5.14.1 .)

The solution is very simple, as expected:

chmod -R 750 /oracle/product/12.1.0.1/dbhome1/perl

The user that I was using is a member of the oinstall group:

mgogala@medo ~]$ id
uid=1000(mgogala) gid=1000(mgogala) groups=1000(mgogala),10(wheel),39
(video),987(vboxusers),1001(oinstall)

The original protections for the package files (.pm) and libraries is
700, which means that only owner can see them. As soon as the group was
added, the utility started working as expected:

[mgogala@medo ~]$ oerr ora 257
00257, 00000, "archiver error. Connect internal only, until freed."
// *Cause: The archiver process received an error while trying to archive
// a redo log. If the problem is not resolved soon, the database
// will stop executing transactions. The most likely cause of this
// message is the destination device is out of space to store the
// redo log file.
// *Action: Check archiver trace file for a detailed description
// of the problem. Also verify that the
// device specified in the initialization parameter
// ARCHIVE_LOG_DEST is set up properly for archiving.
[mgogala@medo ~]$

This doesn't compromise security since the perl modules are only usable
by the members of the oinstall group, which is not given to just anyone.
This looks just like a stupid testing mistake, I will report it on MOS
community forums.

--
Mladen Gogala
The Oracle Whisperer
http://mgogala.byethost5.com

[Frank Langelage]

Similar but not exactly equal on Solaris SPARC 10:
oerr ora 257
/opt/oracle/product/o12cR1/bin/oerr:
/opt/oracle/product/o12cR1/perl/bin/perl: cannot execute

Directory rights are fine:
ls -l /opt/oracle/product/o12cR1/perl
total 6
drwxr-xr-x 2 oracle dba 1024 Jun 26 2013 bin
drwxr-xr-x 4 oracle dba 512 Jun 26 2013 lib
drwxr-xr-x 4 oracle dba 512 Jun 26 2013 man

But permissions of files within those dirs are not, e.g.
ls -l /opt/oracle/product/o12cR1/perl/bin/perl
-rwx------ 1 oracle dba 2730784 Dec 19 2011
/opt/oracle/product/o12cR1/perl/bin/perl

[Mark D Powell]

Thank you both for the information. It would seem Oracle has been messing up the file permissions since 10g. At least Oracle is consistent. 8-D

Mark D Powell

[joel garry]

Rilly. Everyone is so concerned about rpc's or whatever sitting out there since the last century, ( http://www.securityfocus.com/bid/64856/discuss ) while poor jr. DBA's are setting everything to 777 to try to make it all work.

jg
--
@home.com is bogus.
http://www.thewire.com/entertainment/2014/01/jeopardys-newest-star-proves-optimal-strategy-really-unfriendly/357609/

[Mladen Gogala]

On Tue, 04 Feb 2014 13:29:07 -0800, Mark D Powell wrote:

> Thank you both for the information. It would seem Oracle has been
> messing up the file permissions since 10g. At least Oracle is
> consistent. 8-D

And my boss did tell me not to play with the new versions at least until
the first major patchset. What can I do when I'm stubborn?

[Mladen Gogala]

On Wed, 05 Feb 2014 01:43:28 +0000, Mladen Gogala wrote:

> On Tue, 04 Feb 2014 13:29:07 -0800, Mark D Powell wrote:
>
>> Thank you both for the information. It would seem Oracle has been
>> messing up the file permissions since 10g. At least Oracle is
>> consistent. 8-D
>
> And my boss did tell me not to play with the new versions at least until
> the first major patchset. What can I do when I'm stubborn?

And the story ending:

OERR UTILITY DOES NOT WORKS AS A NON-ORACLE USER WHICH IS PART OF OWNER
GROUP (Doc ID 1610673.1)