[Info-vax] "Trusted" detached processes

[H Vlems]

On 12 sep, 13:46, "Richard Maher" <maher... at hotspamnotmail.com> wrote:
> Hi,
>
> For many years now Tier3 has been using the PRC$M_TCB when $CREPRCing our
> detached Communication Server processes, and everything is just peachy. In
> the UAF, we happily update/maintain the last non-interactive login time and
> the number of login failures since last successful login, and all the while
> $SETUAI et al is happy to leave the auditing to us.
>
> Some of the main benefits of this approach are: -
> 1) Security - The user and/or System Manager is able to accurately identify
> when someone last logged into this account and also if there've been any
> failure attempts since last successful login.
> 2) Dormant account clean-up - Accounts that are used solely as server
> accounts and will never be logged into interactively, don't get incorrectly
> disabled for being "dormant".
> 3) No ridiculous stream of "UAF modification" audit messages clog up the
> console and audit logs.
> 4) We get to structure audit messages and content to best suite the
> environment
>
> So what's the problem? Well for many years (even longer than the resistance
> of intrusion detection) Rdb resisted the benefits of (1) above, but finally
> caved in to the demands of System-Managers/DBAs who were sick of having to
> re-enable their ODBC server accounts that were falsely targeted for being
> dormant (2). But they chose not to deploy the /TRUSTED qualifier and
> therefore did not obtain benefit (3). The really odd thing here is that,
> when faced with the backlash from SMs and DBAs about a now cluttered and
> unusable console log, they chose not to simply flip a bit when creating a
> server process but rather to deploy some half-arsed logical name that will
> prevent UAF updates until a given interval has elapsed :-(
>
> Given that the people involved with the Rdb fudge were fully aware of the
> possibilities of PRC$M_TCB, I'm left wondering if there is something
> intrinsically flawed with this approach or if it's simply a case of the
> people who made the decisions being a bunch of recalcitrant numpties - any
> thoughts?
>
> Regards Richard Maher
>
> PS. I don't think "login failures since last successful login" has ever been
> on the Rdb radar.
>
> PPS. Can't remember what ACMS does - anybody?

ACMS: wasn't it DEC's transaction manager for VMS, similar
functionality as IBM's CICS product?
ACMS maintained lists of tasks (executables actually, under VMS) and
made sure only one version was available to run.
Users connected to ACMS without having ever to see a VMS logon screen
or VMS prompt.
That's what my memory seems to remember.....
Hans