Hello, folks,
sorry for the late summary, but here it goes:
I asked :
>Our AS250 4/255 runs DU4.0b and has C2 (ENHANCED SECURITY) enabled. The
>problem is that
>people cannot access the dtlogin on our Alpha from their PCs using X11
>emulation software
>for Windows.
>
>When a query is sent to the Alpha, it pops up a message box saying:
> "Cannot obtain database information on this terminal"
>
>As far as I know all X terminals and ttys on a trusted system must have an
>entry in
>/etc/auth/system/devassign and /etc/auth/system/ttys databases. These entries
>can be
>inserted there either manually, or by using dxdevices program.
>
>And here two problems arise: dxdevices has two fields to be filled for an
>X-term:
>"X display name" and "Device list" - I was unable to find proper documentaion
>on what these
>fields have to contain for an X-terminal.
>
>What do managers have to say about this? Any help will be appreciated.
Answer in brief is:
either each terminal (X display) in this case or a wild card should be added to
/etc/auth/system/devassign.db and /etc/auth/system/ttys.db databases.
Ideally you would use dxdevices for that, but it seems to malfunction and doesn't update
the database. In /usr/tcb/bin lives it's command line counterpart called edauth which can
be used to edit the databases from the cmd line. The syntax of /etc/auth/system/ttys and
devassign as well as thorough explanation of the precedure was best described by Spider
Boardman <spider_at_Orb.Nashua.NH.US> and so I'm quting his entire reply, before I do this,
I'd like to thank all those who answered:
Marie-Claude Vialatte <mc.vialatte_at_custsv.univ-bpclermont.fr>
Surash Natarajan <SURASH_at_omc.otis.com>
Jeff Payne <payne_at_solg2.bnsc.rl.ac.uk>
and special thanks to Spider Boardman <spider_at_Orb.Nashua.NH.US>
------
>>>>> On Tue, 10 Jun 1997 12:52:21 +0200, "Igor V. Alekseev" wrote (in part):
Igor> Our AS250 4/255 runs DU4.0b and has C2 (ENHANCED SECURITY)
Igor> enabled. The problem is that people cannot access the
Igor> dtlogin on our Alpha from their PCs using X11 emulation
Igor> software for Windows.
Igor> When a query is sent to the Alpha, it pops up a message box
Igor> saying: "Cannot obtain database information on this
Igor> terminal"
Igor> As far as I know all X terminals and ttys on a trusted
Igor> system must have an entry in /etc/auth/system/devassign and
Igor> /etc/auth/system/ttys databases. These entries can be
Igor> inserted there either manually, or by using dxdevices
Igor> program.
It turns out that dxdevices is broken for adding new X displays,
so your problems aren't too surprising. However, given that
XDMCP is used to manage the connections in the first place (by
either xdm or dtlogin), you may not need to use dxdevices. In
particular, new with v4.0 was X display wildcard support for the
ttys and devassign databases. It doesn't seem to be documented,
though. So, first, I'll describe what works to add the wildcard
entries, then I'll describe what belongs in the device list for
non-wildcarded X display entries.
To add the wildcards, execute the following (assuming ksh or sh,
since I've not tested this with csh):
/tcb/bin/edauth -dt -s <<-\X
*\:*:\
:t_devname=*\:*:t_lock_at_:t_login_timeout#0:t_xdisplay:\
:chkent:
X
/tcb/bin/edauth -dv -s <<-\X
*\:*:\
:v_devs=*\:*:v_type=xdisplay:chkent:
X
Now, in general, X display specifications are of the following form:
<node>[:]:<display>[.<sub-screen>]
The :: version is for DECnet, which is hardly ever relevant for X
any more, so I'll ignore it in what follows. Also, the node-name
portion can be any of the IP address as a `dotted quad', the
fully-qualified domain name (this is what it's usually supposed
to be), or, if it the two hosts are in the same sub-domain, it
can be just the `short name' (without the domain information).
In the X library, if the serving host knows its own
fully-qualified domain name (which it should), any such `in-zone'
nodenames will be shortened. Thus, on my server,
Orb.Nashua.NH.US, I would expect to see an X connection from
nedspc.Nashua.NH.US show up as "nedspc:0", but one from
alex.Hollis.NH.US would show up as "alex.Hollis.NH.US:0".
However, for robustness of operation, one should add an entry
with each possible form for how it could be seen. For example:
/tcb/bin/edauth -dt -s <<-\X
146.115.237.253\:0|146.115.237.253\:0.0|orb.nashua.nh.us\:0|orb.nashua.nh.us\:0.0|orb\:0|or
b\:0.0:\
:t_devname=orb\:0:t_lock_at_:t_login_timeout#0:t_xdisplay:\
:chkent:
X
/tcb/bin/edauth -dv -s <<-\X
orb\:0:
:v_devs=146.115.237.253\:0,146.115.237.253\:0.0,orb.nashua.nh.us\:0,orb.nashua.nh.us\:0.0,o
rb\:0,orb\:0.0:\
:v_type=xdisplay:chkent:
X
Now, that shows an over-qualified set of names, but it's the true
full form. In fact, given the '-dt' entry, which has all names
by which it could be seen, the wildcard '-dv' entry would be
fine. The device list for devassign (the v_devs field) is
checked for every entry in the devassign database if an incoming
request is not matched in the ttys database. Given a full set of
alternate names (the |-delimited fields before the first : which
wasn't escaped with a \ is the entry-name field, with the |'s
separating synonyms for the entry), the v_devs list should never
be relevant for that reason, and can just contain the name of the
devassign entry itself (which must be what's given in the ttys
entry for t_devname and must be one of the names for the entry in
the ttys database).
Hmm. I hope that was clear enough. In effect, even if you want
to manage the `ttys' entries by adding them explicitly, you can
still use a wildcard devassign entry so long as the list of
alternate names for each ttys entry is complete.
For the above example, the alternates using the unqualified name
of `orb' should only be present for a server in its same
sub-domain, in case that wasn't already clear.
Well, I hope this helps.
--
Spider Boardman (at home) spider_at_Orb.Nashua.NH.US
The management (my cats) made me say this. http://www.wp.com/spider/
PGP public key fingerprint: 96 72 D2 C6 E0 92 32 89 F6 B2 C2 A0 1C AB 1F DC
-------
Thanks,
Igor
Received on Thu Jul 03 1997 - 12:53:37 NZST