Access issue on system volume

[Miles Cosseboom]

Hi - we have an old vms 6.1 system that just a week ago started give us permission issues with folders that are referenced in command procedures like login.com or user menus. All they did is w:re access which is on all folders, files yet user gets permission issue errors. If we set sysprv they are ok. Any idea how to fix without sysprv being used?

[Jan van den Ende]

Miles,

to begin with: WELCOME to the VMS forum!

Let me try if I understand your problem correctly.
The users have access problems on files in their SYS$LOGIN ("home dir" , in Unix speak)
Or are those procedures calling files from other environments, which give the issues?

ANd you (they?) have set W:RE access to all files and directories?
Giving users SYSPRV (VERY diasadvisable!!) overcomes the Insufficient Privilege errors.

Two possibilities: they forgot some important files or directories (maybe even on another drive!)
Or: Some files have AVL protection activated. That protection takes precedense over the SOGW mask, but is overruled by privilege.

Enable Auditing, setting alarm on file access failure, and monitor which files are reported. Check (and repair) the access security on those.

If you need more specific info, please ask.

Success.

Proost.

Haveo one on me.

jpe

[Miles Cosseboom]

what is the command to enable auditing and how do you set the alerts on file access issues?

[EdgarZamora_1]

$ set audit/alarm/ena=access=failure

[Miles Cosseboom]

The failures would then show in the operator.log or which file?
Thanks

[EdgarZamora_1]

the /alarm will send the messages to the operator console (or enabled terminals). If you want it sent to the audit file you can use /AUDIT instead of /ALARM

[Miles Cosseboom]

Thank you very much.
This helped us resolve the issue.
I had to set file/prot=w:re on 000000.dir
on the disk users were having problems accessing files in sub folders.
We still do not know how this was removed a week ago.
Again thank you very much.
Miles

[Robert Gezelter]

Miles,

SYSPRV will override most access checks, and thus should not be used on a general basis.

I would suspect that something was changed, either in the file protections OR in the protections of the higher level directories. Without knowing which file(s) are involved, it is impossible to be specific.

Turning on auditing, as has been described in previous responses, is one option. Another option is including a SET VERIFY command in the LOGIN.COM file to display the commands as they are executed.

- Bob Gezelter, http://www.rlgsc.com

[Miles Cosseboom]

it is my plan to remove one by one the sysprv access we granted as we test the handful of accounts we gave that access to now that we have set the correct prot on the 000000.dir.

Thanks guys.