Insufficient privileges to submit a batch job for a new user

[Cindy Lomas]

I created a new user using Authorize. I copied an existing user who had similar privileges etc. and assigned a new UIC, password, device, directory and lgicmd to the new user.

When I submit a batch job from the new user account, I get %RMS-E-PRV, insufficient privilege or file protection violation. No log file is created.

I had this problem with another user that I created but I assigned it a different UIC and now it's working.

What am I missing?

Thanks,
Cindy

[labadie_1]

the message say this user can't access the batch file.

I think

$ dir /sec com-fil
will show that this file and the user have not "enough" in common

can you post it, and
$ mc authorize sh failing_user
to see the uic, privileges and login directory

[Cindy Lomas]

As requested, here is the user's information.

Username: ORA_USER_MKT Owner: ORACLE Conversion
Account: DEVELOP UIC: [100,54] ([DEVELOP,ORA_USER_MKT])
CLI: DCL Tables: DCLTABLES
Default: DKB100:[ORA_CONV]
LGICMD: SYS$LOGIN:LOGIN.COM
Flags:
Primary days: Mon Tue Wed Thu Fri
Secondary days: Sat Sun
No access restrictions
Expiration: (none) Pwdminimum: 6 Login Fails: 0
Pwdlifetime: (none) Pwdchange: 11-MAR-2004 12:58
Last Login: 11-MAR-2004 13:23 (interactive), (none) (non-interactive)
Maxjobs: 0 Fillm: 100 Bytlm: 64000
Maxacctjobs: 0 Shrfillm: 0 Pbytlm: 0
Maxdetach: 0 BIOlm: 150 JTquota: 4096
Prclm: 8 DIOlm: 150 WSdef: 2000
Prio: 4 ASTlm: 250 WSquo: 4000
Queprio: 0 TQElm: 10 WSextent: 16384
CPU: (none) Enqlm: 2000 Pgflquo: 50000
Authorized Privileges:
GRPNAM NETMBX TMPMBX
Default Privileges:
GRPNAM NETMBX TMPMBX

[labadie_1 · Accepted solution]

so this user uic is 100,54

dir:sec of the com-file that he can't submit in batch gives what ?

[Uwe Zessin]

Cindy,
please check the ownership of DKB100:[000000]ORA_CONV.DIR;1 - it sounds like this directory is not owned by ORA_USER_MKT.

You can check this with:
$ directory/security DKB100:[000000]ORA_CONV.DIR

The correction, usually, is:
$ set FILE/OWNER=[ORA_USER_MKT] DKB100:[000000]ORA_CONV.DIR;1
$ set FILE/PROTECTION=(O:RWE) DKB100:[000000]ORA_CONV.DIR;1

The same should be applied to DKB100:[ORA_CONV]*.* and all files below that directory.

(I just can make myself comfortable with '$ SET SECURITY' for such an easy mission ;-)

[Cindy Lomas]

Thank you very much. Your questions lead me to find the solution. The LOGIN.COM had

SET PROTECTION= (S:WRED,O:WRED,G:WRED,W:RE)/DEFAULT

When I removed this, the command procedure ran successfully. I guess the default protection wasn't enough to allow the user to write to the current directory.

Cindy

[Uwe Zessin]

Cindy,

are you sure you have not changed anything else? That command sets the default protection for files created by the current process. The ability to create files in a directory depends on:

- the current UIC of the process
- UIC-ownership and access control list of the directory
where the file is going to be created
- UIC-ownership, access control list and version numers,
if there is at least one file with the same name.
- the privileges of the current process
I see than ORA_USER_MKT does not hold any file-related ones
- anything else I have forgotten;-)

Do you still have an old DIRECTORY/SECURITY from the directory so we can take a look at it together?

[Willem Grooters]

Cindy,

This user should have read+write+execute access on DKB100:[ORA_CONV], meaning DKB100:[000000]ORA_CONV.DIR should have at least W:WRE. Depending who is the owner:

Owner = ORA_CONV: prot=O:RWE, G:RE, W:
Owner = ORA group, prot = O:RWE, G:RWE, W:
Owner = other: prot= W:RWE.

Write access s required for writing a logfile. Not really reequired if you specify a
You also specified "SYS$LOGIN:LOGIN'COM" in authorize - you can safely remove this - it's the default. Anyway, be careful using logical names and concealed devices in specifications like these: all should be defined /SYSTEM (never tried /GROUP for these, might be usable as well). SYS$LOGIN is a process logical, but probably can be used safely in this context (is setup by the system) but other /PROCESS won't - are setup by LGICMD - just specified here...

[Willem Grooters]

Sorry, Missed out part...

Write access s required for writing a logfile. Not really reequired if you specify a logfile on another location (/LOG=). Don't forget the user should have WRITE access to that location.

[Uwe Zessin]

SYS$LOGIN and SYS$LOGIN_DEVICE are in the job logical name table on my systems.