[Info-vax] Desirable features for VMS

[Stephen Hoffman]

On 2024-01-25 20:20:09 +0000, Arne Vajhøj said:

> On 1/25/2024 8:21 AM, Simon Clubley wrote:
>> A random sample of things from Linux/Unix I would like to see in VMS:
>> 
>> Mandatory Access Controls (my preference) or jails (Stephen's preference).
> 
> The market want containers.
> 
> I suspect that means Hoff jails with a marketing label of "container" 
> instead of "jail".


Jails / sandboxes can be used as a component of containers, but—as I've 
commented elsewhere—containers are far too reminiscent of licensing 
arbitrage. Which can somewhat dampen vendor enthusiasm.

Getting a working jail / sandbox on OpenVMS is no small project, both 
for VSI, and for the app developers adopting jails / sandboxes.

Still involved but smaller in scope would be some variation of the 
pledge(2) mechanism. An aeon or two ago, I'd discussed that and the 
related trade-offs with a then-VSI developer. Deets: 
https://man.openbsd.org/pledge.2

What OpenVMS traditionally implements as system-wide stuff like 
usernames doesn't map all that well.

Jails / sandboxes can be built upon some of the parts of mandatory 
access controls, but I ~never want to have to use a system configured 
for SEVMS-style MAC. Jails, sure. SEVMS-style MAC, not so much.


> 
>> A shell with decent modern functionality such as:
>> 
>> 	Proper command history retention and merging from multiple sessions
>> 	Easy searching of command history
>> 	Tab completion
>> 	Editing long command lines
>> 	Globbing
> 
> +better control structures
> +better data types
> 
> But I doubt it makes sense business wise.
> 
> VMS got:
> * DCL for backwards compatibility
> * GNV bash for *nix compatibility
> * Python and Perl for more programmatic scripting
> 
> Even though DCL2 or XDCL would be nice then I don't think it will 
> increase VMS sale.


Likely not perceived as an increase sales. Though as happened with DII 
COE, sometimes major customers will establish requirements here.

There are a lot of things in this same general category too, which is 
the other side of facilitating and encouraging new adoptions.


>> Proper package management
> 
> Traditional Linux package management at the OS level would
> be the wrong path. The result is a mess.


OpenVMS packaging and installation is already a spectacular mess, but 
then I'm in a charitable mood today.

And the packaging ties into installation, upgrades, removal, app 
isolation, startup, shutdown, code-signing, and jails / sandboxes. 
Among other areas.

And any new scheme will have to contend with apps arriving via cargo, 
nix, pip, cpan, or another installation system, as well.


> The right approach is package management at the application level.
> 
> maven, nuget, pypi, npm, composer etc. not yum, dnf etc..
> 
> For managing the truly OS stuff relative little is needed. PCSI2 or XPCSI.
> 
>  >                                     and management of updates.
> 
> An option for more automated updates of VMS would be nice.


It'll be nice to implement some of the many features that have become 
common in the years since the existing 1988-era designs, yes.


> 
>> Loadable and unloadable kernel modules, with device 
>> driver/filesystem/etc functionality available from within these modules.
> 
> Nice.
> 
> But again I doubt it will increase VMS sale.
> 
>> ASLR and KASLR support.
> 
> That would probably come as part of ongoing security enhancements at 
> some point in time.


Stack canaries might be easier.


>> Proper timezone management. (Everything is always UTC based, and your 
>> timezone is merely a local session property with no effect on the 
>> on-disk timestamps).
> 
> Nice but tricky to implement without breaking stuff.


That's been the compatibility hobgoblin ~forever.  The quadword format 
is embedded all over the place. For some sites, switching to UTC as the 
base works fine.

I've run OpenVMS servers set to UTC at various installations, too, 
("Oh, that? Yeah. The server is in England." usually suffices.)

Downside is that saved dates can be off by a day pending a rewrite, 
which can absolutely be a non-starter for some sites.



PS: The discussion of ASLR/KASLR and buffer-overflow protections 
reminds me of this XPM exploit (whether it also hits XBM?) recently 
discovered: 
https://jfrog.com/blog/xorg-libx11-vulns-cve-2023-43786-cve-2023-43787-part-two/ 



-- 
Pure Personal Opinion | HoffmanLabs LLC