topic Re: ACL or file permission issue in Operating System - OpenVMS

ACL or file permission issue

Kevin Carter_3 — Thu, 15 Apr 2010 23:08:11 GMT

This question involves renaming a file owned by one user to a directory owned by another user. The 2 user accounts involved are savftp and savjob.

The savftp account is a drop off point for files that are processed by user savjob.

The default directory for savftp has the following acl entries:
Directory USR$DISK1:[000000]

SAVFTP.DIR;1 [SAVFTP] (RWE,RWE,RE,)
(IDENTIFIER=[SAVJOB],OPTIONS=DEFAULT,ACCESS=READ+DELETE)
(IDENTIFIER=[SAVJOB],ACCESS=READ+WRITE+DELETE)

User savjob processes the file in the usr$disk1:[savftp] directory. After processing the file user savjob attempts to rename the file to a directory owned by savjob on the same device. The rename fails with the following errors:

%RENAME-E-OPENOUT, error opening USR$DISK1:[SAVJOB.ENTDBA.ARC]TO_RECONCILE.OLD;
as output
-RMS-E-ENT, ACP enter function failed
-SYSTEM-F-NOPRIV, insufficient privilege or object protection violation

As you can see the error happens when savjob tries to write to its own directory.

This process worked prior to migrating from another server with the same OS version, which by the way is OpenVMS 8.2, both systems are at the same patch level.

The old file in the USR$DISK1:[SAVJOB.ENTDBA.ARC] has its protection set to (RWED,RWED,RWED,)

When the new version of TO_RECONCILE.OLD is written it comes with the ace (IDENTIFIER=[SAVJOB],ACCESS=READ+DELETE)

Directory USR$DISK1:[SAVJOB.ENTDBA.ARC]

[SAVFTP] (RWED,RWED,RE,)
(IDENTIFIER=[SAVJOB],ACCESS=READ+DELETE)
TO_RECONCILE.OLD;1335
[SAVFTP] (RWED,RWED,RWED,)
TO_RECONCILE.OLD;1334

If I remove the ace and set the file permissions to be the same as TO_RECONCILE.OLD;1334; the job works once.

The next run fails with the errors previously listed.

How do I fix this?

Thanks in advance

Kevin

Re: ACL or file permission issue

Hoff — Thu, 15 Apr 2010 23:31:00 GMT

SAVJOB needs write access to the directory to SAVFTP.DIR, as a start. (The RENAME requires SAVJOB to update that directory file.) That's the apparent trigger here, though there may be others lurking.

In general, a tool to use here is file access alarms. Or audits, on a busy system. Enable file access failures. That'll tell you what failed.

If the commands can (also) be run interactively, another tool is "SET WATCH /CLASS=MAJOR FILE" or SET WATCH /CLASS=ALL FILE" such; the CLASS varies. Use SET WATCH /CLASS=NONE FILE" to shut off output. CMEXEC or CMKRNL is required. Look for the failure codes.

You can translate these failure codes with, for instance:

$ exit %x910
%SYSTEM-W-NOSUCHFILE, no such file
$

http://labs.hoffmanlabs.com/node/1450

Given you had another system involved, the ACLs can be all over the map if the SYSUAF and RIGHTSLIST don't match. I updated a tool to clean off ACLs for these cases:

http://labs.hoffmanlabs.com/node/426

Re: ACL or file permission issue

Jon Pinkley — Fri, 16 Apr 2010 07:41:10 GMT

Kevin,

What does the following command show?

$ directory/security USR$DISK1:[SAVJOB.ENTDBA]ARC.DIR

What is the raname command being used?

You may want to use rename/inherit_security

$ help rename /inherit_security

Jon

Re: ACL or file permission issue

Kevin Carter_3 — Fri, 16 Apr 2010 19:04:00 GMT

The access issue was determined by enabling file access failure alarms, this enabled me to determine why the rename was failing.