[Info-vax] Creating an audit ACL/ACE

[Stephen Hoffman]

On 2018-08-19 05:57:46 +0000, Jan-Erik Sderholm said:

> The file contains configuration parameters for work stations in the 
> factory. It is edited with VT-screen application where you can display 
> a record, edit and press "save". The issue is that we see unexpected 
> updates to the file. A simple logging could easily be added in the 
> application around the place where that "save" button is processed, but 
> I was just trying to see what could be done with the tools at hand...
> 
> And since it is technically possible to write to the file from other 
> sources, I thought it would be better to have the file itself to 
> trigger the logging, then that editing application.

No easy path.

It could be inferred that this environment might lack an integrated 
framework for logging, or that it's a little problematic for whatever 
reason.

Yeah, I know, OpenVMS knows zilch about distributed logging (syslog, 
syslog-ng, etc) and can't make up its mind about its integrated logging 
(OPERATOR.LOG and OPCOM messages, the audit database, the accounting 
database, various and sundry scattered dump files and equally 
scatter-shot .LOG files, integrating with T4 for 
performance-monitoring, and the ever-so-archaic 
write-a-stackdump-to-the-end-user implementation of the last-chance 
handler, etc).  There's also no easy way to capture and process 
specific events using ACEs and custom code, for that matter; you can't 
program an ACE using (for instance) Lua; not short of that pesky 
mailbox and capturing everything.  There's also no easy way to capture 
I/O and there's no FUSE or analogous, which would have helped this 
case; the system service interception is less-than-fun for this case.

Put another way, this whole area of OpenVMS is a complete and utter and 
primitive mess, and it's been a mess for decades, and the resulting 
messes will persist for the foreseeable future.

Which can then leave us with the requirement to add that bespoke 
logging, the associated log-scanning tools and the rest of the baggage 
involved.

Which leaves apps such as yours and mine to adapt or port or write our 
own logging and monitoring tools, and to port or create distributed 
logging tools where those are necessary.

Pragmatically, starting any new app with the debugging, logging and 
monitoring features — and effectively then building the app around that 
— is a more viable approach than many of us have used in years past.  
Retrofitting debugging, logging and monitoring is such sweet sorrow, 
but it's where more than a few of us have been spending some of our 
development- and operations-related time within large and complex 
environments; those apps that are being actively maintained and 
updated, that is.

As for cases where "anything" can write to system- or app-critical 
files, subsystem identifiers are one of the more useful parts of 
OpenVMS for controlling that access.  Subsystem identifiers being far 
better-targeted here than are privileges.

Some related reading...

SSI:
http://h41379.www4.hpe.com/openvms/journal/v8/ssi.pdf

Subsystems:
http://h30266.www3.hpe.com/odl/vax/opsys/vmsos73/vmsos73/6346/6346pro_019.html#index_x_1519 

http://h41379.www4.hpe.com/doc/84final/4527/4527pro_116.html
http://h30266.www3.hpe.com/odl/vax/opsys/vmsos73/vmsos73/6346/6346pro_030.html


-- 
Pure Personal Opinion | HoffmanLabs LLC