com file fails immediately but runs OK when it's renamed

[David R. Hardy]

Somone deleted at least one too many logfiles the other day and caused one of our batch jobs to fail when run, immediately, with the "RMS-E-PRV: insufficient privileges/file protection violation" security/error message. We had a half-dozen people beating their heads against the wall trying to fix it. Yesterday I renamed the com file in the same directory and it ran OK manually, executing everything it was supposed to execute. A "diff" turned up zero differences between the two com files. Why would this be?

[Karl Rohwedder]

Perhaps it runs under a different username when in batch, or perhaps you had privileges enabled when logged in interactively?

regards Kalle

[Hein van den Heuvel]

Hello David,

Welcome to the OpenVMS ITRC Forum.

If a half-dozen folks, supposedly actually looking at the system can not figure it out, how do you expect us to help?
You'll need to show us many more detials, notably about the file protections involved.

On potential setup which will cause a similar problem is when a remain list file does not allow delete. If deletes are not allowed, then new creates are also not allowed as for many users the new file effectively deletes the old one, by making it invisible (harder to read).

$
$
$ create tmp.tmp
aap
Exit
$ create tmp.tmp
noot
Exit
$ set prot=(o,g,s,w) tmp.tmp.1
$ dir/prot tmp.tmp.*

Directory EISNER$DRA3:[DECUSERVE_USER.HEIN.TMP]

TMP.TMP;2 (RWED,RWED,,)
TMP.TMP;1 (,,,)

Total of 2 files.
$ create tmp.tmp
mies
Exit
$ del tmp.tmp.
$ del tmp.tmp.
$ create tmp.tmp
%CREATE-E-OPENOUT, error opening EISNER$DRA3:[DECUSERVE_USER.HEIN.TMP]TMP.TMP; as output
-RMS-E-PRV, insufficient privilege or file protection violation


The manual run may have used different privs, and once a good new file is in place, hiding the overly protected one, all will seem well. But any future simple wildcard delete will leave only the protect one, which in turn will prevent new creates with a priv violation.

Hope this helps,
Hein.

[Steven Schweda]

As usual, it might help to see exactly what
you did. For example, "@ FRED" may differ
from "@ FRED.COM", if "FRED" is a logical
name. Renaming it would evade the logical
name. Many things are possible; too many to
guess.

[Hein van den Heuvel]

Oh, also... what is the COMPLETE error message?

My example shows the message you report, but before it is also shows a critical section indicating it was a failure to create xyz.

At this point we can only speculate whether the real problem was with a priv getting the the command file, or with something it tries to do.

It might help to clarify this for yourself by adding a first lien to the script with:
$write sys$output "hello world"

Hein.

[Gregg Parmentier]

If it's like the similar problem I've had, try the following:

Create a dummy log file with an editor and set the ownership and privileges to the same as other files in the same directory. Then the batch job will use the ownership of the existing file, instead of it's own, when it createsa the new log.

[David R. Hardy]

Thanks to all for the rapid responses; I'll get a chance to play with this job later today and will most likely benefit from your replies despite my paucity of information.

Here are the exact error messages:

%%%%%%%%%%% OPCOM 3-NOV-2006 12:20:27.13 %%%%%%%%%%%
Message from user AUDIT$SERVER on NOAH
Security alarm (SECURITY) and security audit (SECURITY) on NOAH, system id: 1028
Auditable event: Batch process login failure
Event time: 3-NOV-2006 12:20:27.12
PID: 20245EDC
Process name: BATCH_231
Username: PROS_USER
Process owner: [D_MAIL,PROS_USER]
Image name: $1$DIA0:[SYS1.SYSCOMMON.][SYSEXE]LOGINOUT.EXE
Status: %RMS-E-PRV, insufficient privilege or file protection
violation

BATCH1-on-NOAH->
%%%%%%%%%%% OPCOM 3-NOV-2006 12:32:02.38 %%%%%%%%%%%
Message from user AUDIT$SERVER on NOAH
Security alarm (SECURITY) and security audit (SECURITY) on NOAH, system id: 1028
Auditable event: Batch process login failure
Event time: 3-NOV-2006 12:32:02.36
PID: 20242D1A
Process name: BATCH_233
Username: KAIS_USER
Process owner: [D_MAIL,KAIS_USER]
Image name: $1$DIA0:[SYS1.SYSCOMMON.][SYSEXE]LOGINOUT.EXE
Status: %RMS-E-PRV, insufficient privilege or file protection
violation

[comarow]

I don't think it's a matter of the name of the file, but how the file is executed.

What is going on is.... when a batch job is submitted, when the batch process is created, the process actually runs a login, which includes reading the user authorization file and attempting to write a .log file to the default login directory, or another file.

For some reason, this job is unable to complete this login process.

Is the first job being performed in batch, the other interactively? Are they being sumbitted by the same user ID?

If the same file is executed by
exactly the same user with

@myjob

Does it get the exact same results?

Does the order of the job effect it?

Is there a symbol or logical name with the
file name?

Have fun.

[Karl Rohwedder]

Check,

- if both users are able to log in interactively
- the protection of the various login files, e.g. SYLOGIN, LOGIN from UAF-record
- protection on default directory and on the submitted com-file

regards Kalle

[Jan van den Ende]

David,

is the batch job specifying a log file?

If yes, is the log file actually created?

Your error message is from AUTHORIZE, so idf the log file cannot be created, this WOULD be the result.

But. like the others said, too little info to give anything more than speculation.

Proost.

Have one on me.

jpe

[Hein van den Heuvel]

Ah, as the error message bubbled up, the operation which ran into it got lost, only the bare message and messenger remain.

Enabling security auditng for failed operations should give details in the audit log.

But maybe my speculation was close.
What if there was a 'old-name.log' which is protect for delete access by the username fro the job and there is no, or not-protected 'new-name.log'. The log file, by default, takes teh name of the .com file, so your rename could push it to a different security environment.

How about a $DIR/SECU (or $DIR/PROT/OWN ) for both the old log file name and new log file name (all versions).

hth,
Hein.

[David R. Hardy]

Thanks for all the help, folks; we got it working normally again in auto/batch mode, albeit with the changed filename. A mystery we'll explore in our "copious" free time here. Have a great weekend!

[Jan van den Ende]

David,

"Thanks for all the help, folks;"

To express those thanks, review:

http://forums1.itrc.hp.com/service/forums/helptips.do?#33


Proost.

Have one on me.

jpe