Conference bulova::decw_jan-89_to_nov-90

Re: .0

It looks like it should work.  Try defining DECW$DECTERM_OUTPUT to point
to a log file before the create/terminal command and see what kind of
error message you're getting.

				-- Bob

re: .1

Here's the error in the log file:

XIO:  unable to open connection _WSA30:
      after 0 requests (0 known processed) with 0 events remaining.


Any ideas?

Thanks,

Ed

Re: .2

Did the log file also say something like "Can't open display"?

This looks like a "normal" XOpenDisplay failure.  Have you tried things like
checking global pages and global sections?

				-- Bob

Well, my problem seems to be privilege related because I can successfully create
DECterms from the SYSTEM account. My (nonprivd) account has *exactly* the same
process quotas as SYSTEM, only the privs differ. This is what happened
this morning (all systems had rebooted over the weekend):

KAOU28> set display/trans=local/create
KAOU28> create/terminal
%SYSTEM-F-NOPRIV, no privilege for attempted operation
KAOU28> 

The DECterm (process & window) did get created but I had to hit return to
log in (The release notes say /LOGGEDIN in the default). I even tried to
do a create/terminal/detach/loggedin and I still had to hit return to log in.

I believe this /LOGGEDIN business might be was is causing my grief in trying
to start up VWSlat via the create/terminal command (which works great from
the SYSTEM acct).

Your comments are appreciated.

Ed

Re: .4

Does your non-privileged process have TMPMBX and NETMBX privilege?

				-- Bob

re: -.1

Yup, I have the necessary privs... I think I'll run autogen with feedback to
see if this improves anything...

Thanks,

Ed

KAOU28> set display/trans=local/create
KAOU28> create/terminal
%SYSTEM-F-NOPRIV, no privilege for attempted operation
KAOU28> sho proc/priv

 2-AUG-1989 07:22:40.14   User: BOIVIN           Process ID:   2080011A
                          Node: KAOU28           Process name: "BOIVIN_1"

Process privileges:
 TMPMBX               may create temporary mailbox
 OPER                 operator privilege
 NETMBX               may create network device

Process rights identifiers:
 INTERACTIVE
 REMOTE
 SYS$KITS                                resource
 SYS$NODE_KAOU28
KAOU28>

I have the same problem after running autogen & rebooting... Here's more
info on how I start the remote session manager:

1) My workstation goes through a "normal" DECW$STARTUP with WSAx: process
   created on the VS2000.

2) I stop/id the WSAx process on the VS2000 (the login screen disappears)

3) I log onto the VS2000's boot node (using SYSTEM) and do:
	$ set display/node=kaou28/create (kaou28 = VS2000)
	$ run sys$system:decw$startlogin (login screen appears on VS2000)

4) I log into the VS2000 using my regular nonprivd acct. At this point, I
   cannot create any local DECterms on the VS2000 (either through batch or
   interactively after setting host to the VS2000).

Should I be able to do the above?

Thanks,

Ed

Re: .7

>3) I log onto the VS2000's boot node (using SYSTEM) and do:
>	$ set display/node=kaou28/create (kaou28 = VS2000)
>	$ run sys$system:decw$startlogin (login screen appears on VS2000)
>
>4) I log into the VS2000 using my regular nonprivd acct.

You mean you enter your username and password at the DECwindows login screen
on the VS2000?  This logs you into the boot node, not the VS2000, right?
Is your non-privileged account on the boot node in the list of users that have
access to the VS2000 (Security menu in the Session Manager)?

>   At this point, I
>   cannot create any local DECterms on the VS2000 (either through batch or
>   interactively after setting host to the VS2000).
>
>Should I be able to do the above?

Hmmm... Could you be running into the limit of 2 interactive users: privileged
account on the boot node running decw$startlogin with output directed to the
VS2000 + non-privileged account on the boot node running Session
Manager/DECterm with output directed to the VS2000 + non-privileged account
on the VS2000 trying to run DECterm?  I wouldn't expect the account that ran
decw$startlogin to count as a "user", though.

I don't really know why this isn't working.  I've never tried running
decw$startlogin from another window; have other people done this successfully?

				-- Bob

Thanks for your replies Bob,

re: .7
>You mean you enter your username and password at the DECwindows login screen
>on the VS2000?  This logs you into the boot node, not the VS2000, right?
>Is your non-privileged account on the boot node in the list of users that have
>access to the VS2000 (Security menu in the Session Manager)?

	Yes to all of the above but I'm a bit puzzled by your last question.
	Isn't security handled by DECW$SERVER_ACCESS_ALLOWED.DAT on the
	VS2000 (since SM is running on the boot node)? I know the caveats
	about using * here, I'm using * just for this remote SM testing. KAFS30
	is the boot node and KAOU28 is the VS2000. The LAVC cluster alias is
	KAFSU3.

KAFS30> ty SYS$COMMON:[SYSMGR]DECW$SERVER_ACCESS_ALLOWED.DAT;4
* KAFS30 *
* KAOFS *
* KAFSV6 *
* KAFSU3 *
* KAOU28 *
KAFS30>

I've played with this a bit more to try and find a pattern... I think it goes
like this:

When running remote session manager, a nonpriv'd account cannot create any
local (on the VS2000) DECterms *unless* a local DECterm has *already* been 
created by a privileged account (ie. SYSTEM). In this case, the nonprivd user
can create the DECterm but gets the SYSTEM-F-NOPRIV error and must hit return
to log into the created DECterm (regardless of the /LOGGEDIN switch).

In the case where there are no local DECterms, a nonprivd user cannot create
the first local DECterm (the DECW$TE_xx process dies quickly after being
created).

Ed

Re: .9

Is decw$terminal.exe installed with SHARE, SYSNAM and PHY_IO privilege?  If
it is, I don't see why things would be failing.  I don't really know much
about DECW$SERVER_ACCESS_ALLOWED.DAT, so maybe there's something wrong there,
or maybe there a problem with the maximum number of users.  Something else
that could be wrong is that a system file is protected against world read,
although in that case I'm not sure why you can log in after pressing a
carriage return.

				-- Bob

	Perhaps something more familiar with the workings of
	DECW$SERVER_ACCESS_ALLOWED.DAT can take a closer look
	at .9.  But from my reading of it he is using it to
	allow the desired access, and then not doing anything
	with the system manager's security customization.

	My understanding is that when the login is completed,
	the defaults in DECW$SERVER_ACCESS_ALLOWED.DAT are
	thrown away and replaced with the user's security
	settings done through the session manager or the
	DECW$SM_*.DAT files.

	I.e., after loggin in access is denied to anyone
	anywhere, except the logged in user from that specific
	node.

	Dan

re:.10
	Yes DECW$terminal is installed with the proper privs. 

SYSMAN> do mc install /list/full sys$system:decw$terminal
%SYSMAN-I-OUTPUT, command execution on node KAOU28
DISK$KAFS30$DUA0:<SYS10.SYSCOMMON.SYSEXE>.EXE
   DECW$TERMINAL;2                Prv
        Entry access count         = 8
        Privileges = SYSNAM PHY_IO SHARE
SYSMAN>

re:.11
I didn't think the session manager's security database applied to my case
but I tried it anyway. In the SM security database I tried the following:

Transport	Nodename	Username

DECnet		KAFS30		BOIVIN
DECnet		KAFSU3		BOIVIN
LOCAL		KAOU28		BOIVIN
DECnet		KAOU28		BOIVIN

This didn't change anything. I didn't think it would since I don't have an
entry for the SYSTEM account to display locally on KAOU28 and it works fine. I
don't think the problem is related to security (there must be "something" that
session manager sets up so that local DECterms can be created without privs).
I have no problems setting my display to the VS2000 from remote systems as
long as the appropriate entry is in DECW$SERVER_ACCESS_ALLOWED.DAT (ie. I
can fire up fileview from a remote 6220, KAFSV6).

I know running session manager remotely is unsupported in DECwindows V1.0. What
about V2.0? (I suspect it's still unsupported but I'll ask anyway in
case this is QAR material). I'm on holidays next week (gone fishin' :^)) and
will pursue this then.

Thanks for your replies,

Ed