X authorization problems in a mobile environment

[Egbert Eich]

Waldo Bastian writes:
 > On Friday 05 August 2005 06:43, Egbert Eich wrote:
 > >    1. Approach:
 > >
 > >    Introduce a new environment variable XAUTHLOCALHOSTNAME which
 > >    if set takes precedence over gethostname(). It holds the
 > >    local hostname that was set at the time the X session was started
 > >    and thus is used and thus identifies the credential for this session
 > >    in the authority file.
 > >    This variable can be set by the display manager for the
 > >    entire X session. I've fixed xdm and startx to do this, fixes for
 > >    kdm and gdm are on their way.
 > 
 > KDE's kdontchangethehostname also needs fixing, at the moment it changes the 
 > hostname in the authority file after a hostname change is detected. It should 
 > no longer do that if XAUTHLOCALHOSTNAME is used.

Right. The purpose of my email to the architecture mailing list was to
get some feedback if people find the approach objectionable or have
better ideas.
I personally prefer it over background applications that mess with
configuration file entries.

 > 
 > Session management suffers from similar problems btw (iceauth) so maybe you 
 > want to generalize the name to XLOCALHOSTNAME. 

Right. I can change the name easily and we can decide to have a different
name. I'm not very good at finding those and don't spend much time on it ;-)

 > 
 > Maybe Unix needs to have a concept of "HOSTID" 
 > instead. /etc/ssh/ssh_host_rsa_key.pub would work, but is perhaps a bit too 
 > long :-) Oh, look at that, I actually have a "hostid" command from a time 
 > where 32bit was a lot.
 > 

The reason why we need to identify our local host uniquely (without just 
saying it's localhost) in this case is that we may share the .Xauthority 
file among several 'localhosts'.
A host ID like this would definitely help to do this. One could use a 
randomly generated number for this. 

For our authentication purposes one could add different mechanisms for
local hosts (like using SCM_CREDENTIALS with the newly added 'Server
Interpreted' auth mechanism (which augments host based authorization)
can also help solve our problem. I didn't look at this as it would require
some changes to the Xtrans code and a design of a new interface for
ancillary messages between the Xtrans code and the server.
Something I didn't quite have time for.

Egbert.