Re: System UICs

On 2024-06-08 01:08:56 +0000, Arne Vajhøj said:

 You would not do it that way on VMS.
 Depending on the specific requirements you would probably
do one of:
- start daemon under a username with a minimum set of privs (if it just need WORLD and SYSNAM, then it get just those)
- start the daemon under an unpriviliged username and install executable with the minimum set of privs
- start the daemon under an unpriviliged username, don't install the executable with privs but let the program use an UWSS to do the priviliged stuff
- start daemon under a username with SETPRV privilige and let the program use SYS$SETPRV to turn required privs on and off dynamically
- start the daemon under an unpriviliged username and install executable with with SETPRV privilige and let the programuse SYS$SETPRV to turn required privs on and off dynamically

OpenVMS doesn't have concepts related to app (username and UIC) isolation, so the whole area is clunky at best and many of the knobs and settings (including usernames and UICs) are system-wide, and can be prone to collisions. Third-party app installs can easily run afoul of this area with the potential for conflicting system-wide constructs including usernames; with stuff that can collide and requires manual coordination.
Newer API designs and concepts including pledge(2) and related, and related to jails / sandboxing, are lacking on OpenVMS, which means using privileges or probably preferably creating and configuring and using identifiers.
The closest analog to some of the older and clunkier primitives including setuid(2) involves is setting the privileges in the default mask and not set in the authorized mask. (When those privileges in the default are dropped, they cannot be recovered.) And the UNIX UID design is closer to granting the UIC to the user, which is somewhat different from how OpenVMS is organized. OpenVMS sprouted from RSX-11 here, with the UICs coming first and usernames being added later. And this heritage is why all the numeric UICs are still visible around the system, including everybody's favorite [0,0] directory, err, [000000].  Through compatibility efforts, OpenVMS has morphed UICs into a particular form of an identifier in most places (other than the oldest), but that transition is only when looking at the details and is not clearly documented.
Other options for granting access involve subsystem identifiers, which are usually (often? always?) preferable to messing with privileges and UICs.
And the auxiliary server (also known as inetd) is another common way to get processes started under a particular context, as a newer version of using DECnet task-to-task and objects as was common in yet older environments.

So many options.
 If you really want to change identity, then there are a bunch of utilities for it SETUSER, JUMP, PERSONA etc. - I assume that they change both username and UIC.

It's fairly rare to change the user context in recent years, as it tends to play havoc with accountability in the logs and telemetry data. There's also "fun" around the username and its logical names and login context, which some APIs have handled swapping that better than have others.
BTW(1), UICs are a design that originated in the 1970s and quite probably earlier, and various newer systems are using GUIDs to avoid the inevitable messes that are inherent with UICs. OpenVMS does poorly at this whole area, particularly if recycling or reusing UICs. Stale identifiers and stale UICs can be left scattered around the system, quite possibly waiting months or years before causing confusion or exposures around access permission or access blockages. Wrote up a scrubbing tool ACL_SCRUB that was able to contend with this mess, but not sure if that tool is publicly hosted anywhere right now—I still have a copy stashed away locally, if there's interest.
BTW(2), SYSPRV came second, and is the privilege equivalent of a system UIC. The UIC came first.
BTW(3), users assigned system UICs were pretty common in years past, with various folks placing system staff in [2,*], or in one of the other system UIC groups. I used this assignment to gain control of and manage a problematic PDP-11 RSX-11 system an aeon ago.
BTW(4), Some arcana, if you have somebody that's security curious, but not authorized to have privileges—enabling SETPRV in the user's default mask has no effect to system security, other than causing some few folks that do notice some (failing) efforts to try to use that privilege bit.
--
Pure Personal Opinion | HoffmanLabs LLC