DECW$TRUSTED_UNPAUSE in DECwindows V1.3-1 or earlier

[Galen Tackett]

It's documented that DECW$TRUSTED_UNPAUSE didn't work in DECwindows V1.3-1. See Section 3.4, "Desktop Management", in the "HP DECwindows Motif for OpenVMS
Release Notes" at http://h71000.www7.hp.com/DOC/82final/6470/6470pro_004.html
DECW$TRUSTED_UNPAUSE was "introduced" as far back as, I think, V1.2-6, but never worked up through V1.3-1.

Was a public fix for this ever released, for any version of DECwindows that would run on VMS V7.3-2 or earlier?

I ask because we have no software support at present and are stuck for a while with a mix of VMS V7.3-2/-1 (DECwindows V1.3-1/V1.2-6) on our non-production systems, and V7.3 on our production systems. V7.3-2 is downstream at least several months on our production boxes.

When I worked at another site where we had software support, I believe HP supplied us with a fix that worked on at least one pre-V1.5 system, but I don't recall ever seeing a public ECO to fix it.

(My current site DID have software support until about Dec. 2004 but never requested this particular private fix.)

[Hoff]

I've not seen an OpenVMS ECO kit for this, but then I've also not looked for it. Since you're interested, take a look at what's been releases and see if it made it into one of the mainline ECO kits for OpenVMS. (You can look that up as well as I can.) Or shot-gun this, and ECO OpenVMS to current.

Here's the previous discussion on this:

http://forums1.itrc.hp.com/service/forums/questionanswer.do?threadId=604209

Kits involving LOGINOUT and GRAPHICS and UPDATE would be the obvious bits.


Or lob a formal request at HP.

[Galen Tackett]

Hoff,

Thanks for the suggestions. I should have mentioned that the system is running w/ UPDATE V11 plus XFC V4. That's about as current as can be.

We don't have a current support agreement so I can't request the fix that way.

I assume that we can't request a private fix that came out before our support agreement lapsed in Dec. 2004?

[Hoff]

You'd have to ask the nice folks over at HP to know the answer to that question.

The site support contract ended just before V8.2 shipped, so that's not an option. Save through a purchase. And if buying, it'll be the current V8.3 release, or a purchase of this fix.

[Dean McGorrill]

It won't hurt to ask HP. Decwindows support was part of my group, they may have made a
kit with that fixed. I don't know who to contact technically, most of our work went overseas. -Dean

[Galen Tackett]

Closed, but feel free to post additional comments...

[Galen Tackett]

Under a support agreement for a VMS I64 system, the very helpful folks at HP Support and DECwindows Engineering have provided me with a fix for this problem for VMS Alpha V7.3-2 and have said it should be included in the next GRAPHICS ECO.

I learned a few odd things about setting up the trusted unpause account along the way:

1) Don't set the DISUSER, CAPTIVE, or RESTRICTED flags. I was told that DECwindows applications don't support CAPTIVE or RESTRICTED accounts

2)Don't set /NONETWORK, (I was told that DECwindows logins have to have network access even to use the LOCAL transport.)

3) Each time you successfully unlock a screen using the special account's password, you get a Network Login Failure event from the security server. The login failure count is incremented for the special account as well. This is because the authentication mechanism first attempts to use the actual user's account name with the password you just typed at the unlock prompt. When that fails it tries again using the account name from DECW$TRUSTED_UNPAUSE and the same password. This works (assuming you didn't fumble typing the password.)

Engineering told me that all three of these are expected behavior; but I think there might be potential problems arising from this validation scheme.

After some experimenting I set my unlock account like this and so far it works:

/DEVICE= -
/DIRECTORY=[BOGUS] -
/FLAGS=(DISCTLY,DEFCLI,LOCKPWD,DISMAIL,DISIMAGE) -
/NETWORK/NOBATCH/NOLOCAL/NODIALUP/NOREMOTE -
/PRIV=NOALL -
/DEFPRIV=NOALL


Perhaps some of the flag settings are unnecessary or not useful, but I don't know that so I figured I'd use them anyway.

Likewise I'm not sure how much /DEVICE=NLA0: or /DIRECTORY=[BOGUS] really help.

Comments from the security experts?