The Shell and Setting Permissions

Note that absolutely none of this is authoritative or directly based on relevant documentation. It’s mostly what I found and figured out and guessed and (in some cases) made up. Some of it may be wrong or dangerous or lead to disaster or confusion. I am not taking responsibility here for anything, not even spelling or good taste. Read and act on it at your own peril!

Like Windows NT and unlike vanilla Unix or Linux, OpenVMS uses Access Control Lists.

Like Unix and unlike Windows NT, OpenVMS also uses traditional file permissions.

And unlike Windows NT, OpenVMS only protects persistent objects, like files and batch queues but not transient objects like processes. (Processes are secured using a different mechanism.)

OpenVMS permissions are _discretionary meaning that the owner of an object sets the permissions on the owned object.

Like Windows NT and Unix, OpenVMS also supports privileges. (Apparently in Linux those are called “capabilities”.)

And finally, similar to Unix and to Windows NT Just-Enough-Admin, OpenVMS supports the concept of privileged images (programs that run privileged on account of being the program they are) called installed images.

In short, and since I really like tables:

Mechanism	Unix	VMS	Windows NT	Description
object permissions	file permissions (and everything is a file)	access control lists and file permissions	access control lists	what may be done with an object, like a file, and by whom
subject permissions	privileges or capabilities	privileges	privileges	what an actor may do regardless of object permissions
action permissions	setuid bit and sudo	PowerShell Just-Ehough-Admin	installed images	what an particular program or command may do regardless of object or subject permissions

Object Permissions

Access Control Lists

(Don’t forget to run set process/parse_style=extended or add it to your login.com file to allow mixed-case file name handling!)

Benoit’s login directory is owned by Benoit and any new file created in it is also owned by Benoit:

$ show security [-]benoit.dir

SYS$SYSDEVICE:[000000]BENOIT.DIR;1 object of class FILE
     Owner: [BENOIT]
     Protection: (System: RWE, Owner: RWE, Group: RE, World)
     Access Control List: <empty>
$ create TestFile.txt
I am a test file.
 Exit
$ dir

Directory SYS$SYSDEVICE:[BENOIT]

SSH.DIR;1           TESTFILE.TXT;1

Total of 2 files.
$ show security TestFile.txt

SYS$SYSDEVICE:[BENOIT]TestFile.txt;1 object of class FILE
     Owner: [BENOIT]
     Protection: (System: RWED, Owner: RWED, Group: RE, World)
     Access Control List: <empty>
$

In both cases the access control list is empty and only file permissions are configured.

Here the operating system (the system account) is alloed to read, write, execute, and delete and so is the owner (Benoit). Members of the group Benoit belongs to are allowed to read and execute and the world (everybody else) is not allowed anything at all.

To give his friend Le Grand Schtroumpf (user name legrand) access to the secret file TESTFILE.TXT, Benoit has to use the set security command on both the directory and the file.

Currently poor legrand cannot see the contents of the file:

$
VBVMS1::LEGRAND 14:38:26   (DCL)   CPU=00:00:00.03 PF=348 IO=96 MEM=267
$ type dka0:[benoit]testfile.txt
%TYPE-W-SEARCHFAIL, error searching for DKA0:[BENOIT]TESTFILE.TXT;
-RMS-E-PRV, insufficient privilege or file protection violation
$

To allow legrand access specifically, editing the access control list might be the right way. Legrand needs access to both the directy and the file.

$ set security/acl=(identifier=legrand,access=execute) [-]benoit.dir
$ show security [-]benoit.dir

SYS$SYSDEVICE:[000000]BENOIT.DIR;1 object of class FILE
     Owner: [BENOIT]
     Protection: (System: RWE, Owner: RWE, Group: RE, World)
     Access Control List:
          (IDENTIFIER=[LEGRAND],ACCESS=EXECUTE)
$ set security/acl=(identifier=legrand,access=read) testfile.txt
$ show security testfile.txt

SYS$SYSDEVICE:[BENOIT]TestFile.txt;1 object of class FILE
     Owner: [BENOIT]
     Protection: (System: RWED, Owner: RWED, Group: RE, World)
     Access Control List:
          (IDENTIFIER=[LEGRAND],ACCESS=READ)
$

This will allow friend legrand to look (but not modify) the file:

$
VBVMS1::LEGRAND 21:25:02   (DCL)   CPU=00:00:00.06 PF=450 IO=153 MEM=268
$ type dka0:[benoit]testfile.txt
I am a test file.
$

A very good tool to edit ACLs more easily is the ACL editor.

$ edit/acl testfile.txt

Which opens the ACL in a text editor.

(IDENTIFIER=[LEGRAND],ACCESS=READ)
[End of ACL]

Changes can be saved with F10 or ctrl+z or abandoned with ctrl+y.

Old-Style File Permissions

Non-ACL File permissions can be set using the SET PROTECTION command.

$ set protection=(world:r) anothertestfile.txt
$ show security anothertestfile.txt

SYS$SYSDEVICE:[BENOIT]AnotherTestFile.txt;1 object of class FILE
     Owner: [BENOIT]
     Protection: (System: RWED, Owner: RWED, Group: RE, World: R)
     Access Control List: <empty>
$

This allows everyone (world) read access to AnotherTestFile.txt. It is probably be better to add such a permission in the ACL. (Note that the ACL term for “WORLD” is “[*,*]”, as in any user, any group.)

Subject and Action Permissions (Privileges)

Privileges allow a process to perform privileges activities. Really.

For example, running the system dump analyzer requires CMKKRNL privilege.

User legrand cannot run analyze/system because of a missing privilege.

$
VBVMS1::LEGRAND 21:36:46   (DCL)   CPU=00:00:00.14 PF=720 IO=271 MEM=277
$ analyze/system

OpenVMS system analyzer
%SYSTEM-F-NOPRIV, insufficient privilege or object protection violation
$

The system user can run it:

$
VBVMS1::SYSTEM 21:37:19   (DCL)   CPU=00:00:00.04 PF=307 IO=90 MEM=264
$ analyze/system

OpenVMS system analyzer

SDA>

There are now two ways to allow user legrand to run it.

Subject Permissions

One way is to grant user legrand the required privilege. The system user or a user with system privilege has to grant the privilege.

$ set default sys$system
$ run authorize
UAF> show legrand

Username: LEGRAND                          Owner:  LE GRAND SCHTROUMPF
[...]
Authorized Privileges:
  NETMBX       TMPMBX
Default Privileges:
  NETMBX       TMPMBX
UAF>UAF> modify/privileges=cmkrnl legrand
%UAF-I-MDFYMSG, user record(s) updated
UAF> show legrand

Username: LEGRAND                          Owner:  LE GRAND SCHTROUMPF
[...]
Authorized Privileges:
  CMKRNL       NETMBX       TMPMBX
Default Privileges:
  NETMBX       TMPMBX
UAF>

Now, after logging in again, user legrand run can the system dump analyzer, after enabling the privilege for the current process. He can even, ambitious as he might be, disable the privilege and try again (and it won’t work).

$
VBVMS1::LEGRAND 21:45:07   (DCL)   CPU=00:00:00.12 PF=648 IO=189 MEM=273
$ set process/privileges=cmkrnl
$ analyze/system

OpenVMS system analyzer

SDA>  Exit
$ set process/privileges=nocmkrnl
$ analyze/system

OpenVMS system analyzer
%SYSTEM-F-NOPRIV, insufficient privilege or object protection violation
$

Recall that ending a program is done in a constructive way with ctrl+z.

Action Permissions

In order to allow everyone to run the system dump analyzer (why not?), the privilege can also be attached to the program instead of its individual users.

$
VBVMS1::SYSTEM 22:12:57   (DCL)   CPU=00:00:00.37 PF=1289 IO=1013 MEM=295
$ install list sda

DISK$X86SYS:<SYS0.SYSCOMMON.SYSEXE>.EXE
   SDA;1            Open
$ install replace/privileged=cmkrnl sda
$ install list/full sda

DISK$X86SYS:<SYS0.SYSCOMMON.SYSEXE>.EXE
   SDA;1            Open              Prv
        Entry access count         = 0
        Current / Maximum shared   = 1 / 0
        Privileges = CMKRNL
        Authorized = CMKRNL

$ install create/shared sys$share:sda$share.exe
$ install list sys$share:sda$share

DISK$X86SYS:<SYS0.SYSCOMMON.SYSLIB>.EXE
   SDA$SHARE;1      Open Hdr Shared            Lnkbl
$

Yes, sda$share.exe must also be mentioned as a “shared” image.

Since sda.exe is already in the list of “installed images” it needs to be replaced rather than added. (In case of an image that has not already been added replace the replace command with the add command instead of adding the replace command.)

Now user benoit, unprivileged as can be, can run the analuze/system command like a pro:

$
VBVMS1::BENOIT 22:21:06   (DCL)   CPU=00:00:00.15 PF=808 IO=258 MEM=274
$ show process/privileges
[...]
Authorized privileges:
 NETMBX       TMPMBX

Process privileges:
 NETMBX               may create network device
 TMPMBX               may create temporary mailbox

Process rights:
 BENOIT                            resource
 INTERACTIVE
 LOCAL

System rights:
 SYS$NODE_VBVMS1
$ analyze/system

OpenVMS system analyzer

SDA>

The user needs no privileges and no enabling of privileges. The system dump analyzer is just available to the user because the system dump analyzer itself is now privileged.

To undo, that is to remove all privileges from sda.exe (sda$share.exe can remain shared for all I care), this command will do:

$ install replace/noprivileged sda

This will replace the privileged sda entry with a nonprivileged sda. User benoit can now no longer run analyze/system. Trust me.

Next: TBD