[Info-vax] The best VMS features, was: Re: openvms renaming file

[Stephen Hoffman]

On 2018-05-28 05:56:56 +0000, Simon Clubley said:

> On 2018-05-28, Stephen Hoffman <seaohveh at hoffmanlabs.invalid> wrote:
>> 
>> Logical names?  Definitely not.  Logical names are a disaster, in most 
>> of the ways that they're commonly used.   There are better ways to do 
>> most or all of what logical names are used for, too.  Just not as 
>> easily on OpenVMS, unfortunately.   They're complete dreck when used 
>> for app settings, flags and related configuration data.
>> 
> 
> I know they have been heavily abused by the C RTL people (for example) 
> but the idea was good.

For pretty much anything beyond devices and paths — and there are 
equivalent or variously better alternatives there — the use of logical 
names for configurations and settings is a bad idea.   Here's why:

All translations are always text. the parser author has to handle 
translations to strings or quoted strings, or decimal or hexadecimal 
numerics, or generic or app-specific keywords.  And character encodings 
for that matter, though many OpenVMS developers haven't yet realized 
what "fun" that can be.  Which means you get to write your own parser.  
Most folks use simplistic ones, and the processing grows like a weed, 
with unique processing for each setting.  There's no stock parser for 
querying configuration data and settings.  Which means that every 
parser is different.  And in more than a few cases, there's no 
consistency in naming and usage even within the same app.  Some apps 
need 0 or 1, some want TRUE or FALSE, some accept TRUE and 1 or FALSE 
and 0 as the same values, some parsers are case-blind and some are not, 
and generally we get what we have.

Beyond rolling our own parser, we're rolling our own using a 
LIB$SET_LOGICAL call or system services, which is kind of like using 
$qio logical block operations to manage a file system.  It's quite 
possible to do that, but... why?  And we're tossing the management of 
all of this over to end-users or integrators or our own support staff, 
editing configuration files of DEFINE commands manually.  And mistakes 
there don't always get spotted immediately, and sometimes don't get 
noticed until the support call arrives.  More than a few of us won't 
bother with syntax checks and diagnostics.

While we're on the subject of parsers, didn't somebody around here 
notice a bug with parsing.  Could that have been you, Simon?  And that 
was in a commonly-used tool.  Maybe you or others start fuzzing apps 
via configuration logical name.  Many will probably toss errors or will 
ignore errors, but it wouldn't surprise me to find a few flaws lurking 
here.  Then there are the more complex schemes.  And the folks that are 
translating untrusted logical names and probably shouldn't.  OpenVMS 
does try to help there, but there are cases where untrusted logical 
names are translated by trusted apps.  OpenVMS itself had a nasty 
vulnerability lurking here many years ago, around GRPNAM handling.  
https://www.netfunny.com/rhf/jokes/89q4/evild.693.html

Then there's that the logical names as used are volatile data.  Which 
is good and bad.  But it means there's a running translation and 
there's a pile of DEFINE and/or ASSIGN commands somewhere else.  Which 
mean that — for those apps that want or need to make changes, 
automating that is less than easy.

And then there's trying to automate parsing of searchlists and 
concealed rooted logical names — that blows up more than a few apps.  
I've learned to ask if the app or tool is only blowing up in the SYSTEM 
account, because that's often the first time that many developers 
discover the "fun" of SYS$SYSROOT and related parsing.

Developers are left to use some inner-mode hackery or a SPAWN and 
parse-the-output or to use less-than-obvious names or other constructs 
to find all of the logical names associated with settings, or to 
hard-code all of those translations into the app and which makes 
cross-version work and upgrades rather more interesting.  Most of us 
ignore this.

No mechanism for making comments around the settings, except as DCL 
comments located with the ASSIGN and/or DEFINE commands elsewhere.

No API and no command interface for retrieving and possibly changing 
settings, either.

When used for configuration and control, logical names are writing your 
own file system and record system, your own parser, your own syntax, 
and your own everything.  I mean... sure.  Have at.  Just don't tell me 
the fucking disaster we have is top ten.  Because if this morass is 
top-ten, y'all really need to recalibrate how much manure you're 
willing to swim in.

Outside of devices and paths, logical names are just hilariously bad at 
what folks use them for.  This is masked by the detail that many 
OpenVMS programmers are steeped in OpenVMS and haven't used systems 
with tools to manage configuration data.

With devices and paths, links work nicely and OpenVMS does have decent 
support for soft and hard links.  Then there's the whole question of 
reconfiguring apps on the fly.  That's great for development, but — 
particularly around privileged and trusted code — it also makes room 
for messes.

OpenVMS doesn't have a consistent way of managing file-based 
configuration data, whether that data is embedded in the executables 
(q.v. SET DEBUG) or it's using various separate files (q.v. X, 
MODPARAMS, SMTP) or logical names (q.v. C, SMTP, etc).  It's 
inconsistent.  Which makes for complexity and confusion, and sometimes 
for vulnerabilities.  And it makes having profiles and easier 
management vastly more complex.

Put bluntly, nobody working on OpenVMS has particularly looked at 
making changes to apps and bundling and packaging and configuration 
data in decades.  It's all ad-hoc.  And beyond all of the complexity, 
and beyond the difficulties around setting up app and user profiles for 
settings, what we have now doesn't work very well when we're headed 
toward signed apps and increasing restrictions around what files can be 
modified by folks other than by app vendors and by VSI.

The whole logical name table and mode design is quite elegant.  It's a 
very early key-value store.  But logical names are lacking in 
capabilities.  Unfortunately, logical names are just not particularly 
useful what many of us are using those logical names for.  And for 
those RSX-ancestry application cases where we are still dealing with 
devices and paths and related redirections akin to what RSX-11 once did 
— and where logical names still fit — are logical names going to 
continue to be the best way to manage that device and file 
redirections?  Or will we be tightening those controls, and the 
available customizations?  Either for reasons of security, or for 
ease-of-use.   And as for traditional uses of logical names, we're also 
lacking a device and volume manager for those tasks, too.  Device 
management and mounting too is all hand-rolled and hand-edited 
complexity, and even more "fun" in even a slightly-volatile cluster 
configuration.  MSCP_MOUNT, et al.  But I digress.

And to be clear, I can and still do use logical names and homemade 
parsers, because that's what is available.  If I had something akin to 
the macOS user defaults foundation class, and had property lists and 
related, I'd be usually using those and not logical names.  I just 
don't see logical names as a particularly valuable feature.  Which is 
probably also why features akin to logical names aren't common across 
other platforms.  There are alternatives, and variously better ones.

>> I used to think that logical names were pretty handy.  Then I started  
>> working with property lists (YAML or otherwise) and with settings that 
>> were integrated into the image activator, and with file links.  Vastly 
>> preferable, far more capable, and lacking the out-of-band and  
>> collision-avoidance-by-convention issues of logical names.   All of  
>> which OpenVMS lacks.
>> 
> 
> How well do those things work in a shared everything cluster environment ?

Being either embedded in the executable or embedded in the app bundle, 
or resident in a known location (SYS$USER_PREFERENCES, 
SYS$SYSTEM_PREFERENCES, or whatever, akin to DECW$USER_DEFAULTS and 
DECW$SYSTEM_DEFAULTS), generally as well or better than logical names 
do.

>> Privileges aren't  particularly tied to the access modes, beyond the 
>> memory management  controls being the foundation for all security.
> 
> For one obvious example, what exactly is the point of having both 
> CMEXEC and CMKRNL privileges on VMS, given how VMS is designed ?
> 
> Because of that design, CMEXEC is completely and utterly redundant and 
> is just artifical complexity (and a false sense of security).

Ayup.  All of the ALL-class privileges are redundant, from the 
perspective of reality.  They're conventions at best, and not 
security-relevant protections.  And the group- and operator-related 
privileges are nice and sometimes useful, but the whole UIC-based model 
is not really solving current problems around isolation.  It's all left 
over from timesharing, and I just don't see a big future in 
character-cell UIs and time-sharing, nor in non-automatable 
user-assigned UIC settings.  Identifiers and subsystem identifiers (a 
feature that's handy and that's not been mentioned yet) are the path 
forward, and we're probably better off having usernames and associated 
GUIDs for user identification and not manually-coordinated and 
traditional UIC group and member values.

And then there's that "privileges" should better have been named 
"responsibilities", but that particular nomenclature mess is long past 
fixable.

There a whole lot of work here for VSI and for a few third-parties, 
around design and development, around features and capabilities that 
need updates or wholesale replacements, and also around marketing and 
particularly understanding how OpenVMS compares and contrasts with 
other platforms.  Because an integrated and comparatively feature-weak 
key-value store isn't likely going to be a huge selling point...



-- 
Pure Personal Opinion | HoffmanLabs LLC