[nSLUG] .Xauthority and communal directory

Daniel Morrison draker at gmail.com
Mon Aug 16 15:07:54 ADT 2010


Note that setting the XAUTHORITY variable tells programs where to find
the user's already generated Xauthority file, but normally has no
effect on where the X server originally created it's own auth file.

Note the distinction between the user's Xauthority file, which may
contain several different cookies (for instance, when sshing to a
remote system with X11 forwarding on) and the server's private file.

On my system I can see with 'ps' that xinit passed an -auth option to
the Xserver telling it to put the file in -- in my home directory,
probably because I login at the console and type 'startx', rather than
using a graphical logon.

The xauth man page says about 'generate' that it is normally not used
to setup the user's ~/.Xauthority file, instead xdm does that.

In the xdm man page it states:

When  xdm  is  unable  to  write to the usual user authorization file
($HOME/.Xauthority), it creates a unique file name in this directory
and points the environment variable XAUTHORITY at the created file.
It uses /tmp by default.

This sounds like exactly what you want. So if you are using xdm, you
could simply touch /home/common/.Xauthority as root (to make it
unwritable by users) and the correct thing should happen. But I think
perhaps you're only use ssh to get to this DMZ box (it's not quite
clear). The important thing here is that it seems to be OK to /tmp, so
long as the file itself has the proper permissions.

So, we replace the question with how does ssh set the authority file?
That's not so clear, with very little in the man pages about it. I
found this question that seems exactly the same as yours:


but there is no answer.

I found this page:


which discovered that ssh's authority file (stored in
/tmp/ssh..../cookies) was ignored because his OS reset the XAUTHORITY
variable. His solution was to write a little find command to return
XAUTHORITY to the ssh-generated one in /tmp/.

However it dates from 2005, and my ssh currently writes directly to
~/.Xauthority, not in /tmp. If I make my remote ~/.Xauthority file
unwritable, sshing to the remote server fails to setup X forwarding. I
get this error upon ssh:

Warning: untrusted X11 forwarding setup failed: xauth key data not generated
Warning: No xauth data; using fake authentication data for X11 forwarding.

You must be getting this error too?

Ah, I have perhaps found some bad news:


"...[this change] makes it so
that.there is no way to securely change the location of the Xauthority
file to a subdirectory of /tmp (or any other globally-shared temporary

And then if you follow the thread:

"Am I the only one (besides Pekka Savola) who cares that 2.9p2 broke
the ability to store one's Xauthority file outside of one's home

No answer.

I tried his first solution (define XAUTHORITY in
$HOME/.ssh/environment), had to turn on 'PermitUserEnvironment' in
/etc/ssh/sshd_config, and the environment variable did get set, but it
did not solve the problem.

So the only solutions left seem to be: downgrade to ssh before 2.9.p2
(definitely not recommended!), or recompile ssh using the configure
option '--with-auth' and create a little shell script to handle xauth,
or avoid using a common home directory.

Of all the options, I think the last is best. Shared home directories
are generally a bad idea. I would just create them all, empty
(assuming you don't have 20,000 users or something!). A smart PAM
module hacker (not me!) could probably write up something that would
create them on the fly...?


On 16 August 2010 13:32, Ben Armstrong <synrg at sanctuary.nslug.ns.ca> wrote:
> On 08/16/2010 01:17 PM, Eri Ramos Bastos wrote:
>> Thanks, Ben.
>> OK, tried that now. Same issue.
>> I noticed one thing now: The .Xauthority file is not created at all:
>> $ ls -lha
>> total 16K
>> drwxrwxrwx 2 root root 4.0K Aug 16 13:13 .
>> drwxr-xr-x 7 root root 4.0K Jun 24 12:43 ..
>> -rwxrwxrwx 1 root root 2.2K Aug  6 15:31 .bashrc
> If . is /home/common, then you have the same problem as with /tmp. the
> permissions are too liberal.
> Ben

More information about the nSLUG mailing list