Path: ...!eternal-september.org!feeder3.eternal-september.org!news.eternal-september.org!.POSTED!not-for-mail
From: Stephen Hoffman <seaohveh@hoffmanlabs.invalid>
Newsgroups: comp.os.vms
Subject: Re: System UICs
Date: Mon, 10 Jun 2024 15:26:11 -0400
Organization: HoffmanLabs LLC
Lines: 95
Message-ID: <v47k0j$jhpn$1@dont-email.me>
References: <lcg1n2Fm6huU1@mid.individual.net> <v3ut10$22bph$1@dont-email.me> <v407j1$298kq$1@dont-email.me> <v40av8$29vru$1@dont-email.me>
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Transfer-Encoding: 8bit
Injection-Date: Mon, 10 Jun 2024 21:26:12 +0200 (CEST)
Injection-Info: dont-email.me; posting-host="244bcd63d3729afd827dd7290ec5cf9f";
	logging-data="640823"; mail-complaints-to="abuse@eternal-september.org";	posting-account="U2FsdGVkX1/SaOOPcRyH8xaBSGX5YH2wM+cUkDrwUbE="
User-Agent: Unison/2.2
Cancel-Lock: sha1:P4pZV6LblLJL93sk44H6f+Rqr54=
Bytes: 5728

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