Conference bulova::decw_jan-89_to_nov-90

Whenever you get "Client is not authorized to access server", the access
failure should be logged in SYS$MANAGER:DECW$SERVER_0_ERROR.LOG.  That
should give you a clue as to what the problem is.  Please post the contents
of the log file, even if the error is obvious.  I'm interested in learning
what kinds of difficulties people encounter.

I got the following mail message in response to .0 (reprinted with the permis-
sion of the author 8^):

From:	38863::DERAMO "Daniel V. {AITG,ZFC}:: D'Eramo  04-Jan-1990 1502"  4-JAN-1990 15:04:00.26
To:	ARTFUL::SCOTT
CC:	
Subj:	DECwindows note 2001.0 "DECnet and Opening Windows from Ultrix"

	Michael,

	On my VMS workstation I have two security entries for me
	for an ULTRIX node (Blake) using DECNET:

		BLAKE DERAMO
		BLAKE 21

	The 21 is the user number on the ULTRIX system ... grep your
	username in /etc/passwd if you don't know it

		$ grep deramo /etc/passwd
		deramo:IITYWIMWYBMED:21:10:Daniel V. D'Eramo:/staff/deramo:/bin/sh

	The third field (between the second and third colons) is the
	user number.  I think most ULTRIX clients use it, but "setuid"
	clients use the username (I suppose VMS upcases it).

	Dan

Given this, I deleted the wildcard entry from the security list and included
an entry giving the username (in addition to the one giving the user number).
xterm works now.

I'm no "X-pert", but this doesn't seem like a good thing.  How is it possible
for "'setuid' clients" to give a different ID to the server than other appli-
cations?  Isn't that stuff all specified for the application by X-window
routines?

BTW, this came up when I tried starting an application which comes up initially
with a control panel *and* an xterm.  The control panel came up successfully,
and the xterm did not.  Yet the application worked perfectly when using TCP/IP
as a transport.


RE: .1

Thanks--I checked the log, and it contained very nice error messages saying
that connection attempts had failed, giving the system, username and transport.
If I'd looked at this I would have seen the problem immediately.  Thanks for
the tip.

This is very interesting.  Thanks for the info.  I'm not sure what the
right thing to do is, but at least for now we can tell users to put both
the user ID and the user name in the security list.  

The security information for VMS is not supplied via Xlib routines.
The VMS server does all its security checking through information
supplied by DECnet (or TCP/IP as the case may be).  DECnet supplies
the node name and user name.  TCP/IP only supplies the node name.

This is currently the only practical way to do security checking.  Xlib
does nothing magic for you, all it does is format X protocol packets.
If the security information was passed via the protocol, it would be
very easy for someone to fool your security setup simply by passing
a bogus node name and user name.

It is theoretically possible to pass the node name and user name using
some kind of encryption system that prevents spoofing, but this kind of
system won't be much good until the industry agrees on some standards.

I'm not an Ultrix guru, but someone explained this oddness to me some time ago.

It seems that the username is only available to a process in a file which is
protected such that only system can read it.  If you are normal code, you
can't get at it and all you know is the uid,so that is what you send.  If you
are running root (such as dxterm), then you can get the info and you do.

Burns

Untrue.  The password file is world-readable and any process can perform the
uid to real name mapping.
				Jeff

    So Jeff, is there any germ of sense in .4?  What can be going on here?
    I had several people explain to me that DECnet could not get the
    username info securely unless the program is privileged?  I'm really
    curious!  Could it be that the username is available to all, but not
    trustworthy unless the program is privileged?
    
    Burns

I'm curious too.  I may have had this explained to me once, but all I remember
being told is that this was completely DECnet's doing and had little to do with
Ultrix itself.

I can't imagine how calling getpwent as root is more secure or trustworthy than
calling it as any other user.  Nothing else in Ultrix has this hangup.
				Jeff

>>        Untrue.  The password file is world-readable and any
>>        process can perform the uid to real name mapping.
        
        I thought that more than one line in /etc/passwd may be
        set up to use the same uid.  Knowing the uid or even both
        uid and gid doesn't seem to be enough to determine the
        username in all cases.
        
        Dan

    Unlike VMS, the login name of an ULTRIX user is not available in kernel
    context, only the UID.  dnet_conn(3dn) will attempt to communicate the
    loginname to the kernel.  Now if the process isn't running with an
    effective UID of root, the kernel won't use the supplied name (can't 
    trust the user) and so converts the UID to an ASCII decimal string.
    When the connect is made, the name (if available) will be sent
    otherwise the UID will be sent.
    
    XOpenDisplay(3X) uses dnet_conn(3dn) to establish the X connection.
    Since, dxterm & xterm are setuid-root, they supply the loginname.
    Since most everything else isn't, they supply the UID.
    
    Now don't go setting applications setuid-root!!  If you do, you will be
    setting all sorts of security holes on your system.  An application
    must be coded with the knowledge that it will be setuid-root, otherwise
    it can used to get to root.
    
    In 4.0, we (DECnet-ULTRIX) tried to get the loginname added to the
    process/user structure so we could do the right thing.  Unfortunately
    we failed (it would have required too many changes to too many
    components, etc.).
    
    matt
    [DECnet-ULTRIX (owner of said DECnet kernel code)]

    RE: .9
    
    In that case, why do you _ever_ send the username?  The problem here is
    not in whether we'd rather have the username or the UID, but in that
    the identification should be consistent (at least for X-window
    applications).  One solution would be for dnet_conn to add an optional
    flag argument with which to force the UID to be sent, whether or not
    the username is available.  XOpenDisplay could then use that flag.

>    In that case, why do you _ever_ send the username?  The problem here is
>    not in whether we'd rather have the username or the UID, but in that
>    the identification should be consistent (at least for X-window
>    applications).  One solution would be for dnet_conn to add an optional
>    flag argument with which to force the UID to be sent, whether or not
>    the username is available.  XOpenDisplay could then use that flag.

Historical reasons.  If an application sets proxy_requested to 0, then the
UID will always be sent regardless of the effective UID.