[nSLUG] .Xauthority and communal directory

Eri Ramos Bastos bastos.eri at gmail.com
Tue Aug 17 12:10:56 ADT 2010


Hi, Daniel.

Thanks for the reply.

After reading all those links I ended up doing that:

if [ ! -d "$HOME" ]
then
	mkdir -p $HOME
        echo "Your session needs to be restarted. Please log in again"
	sleep 2
	exit

fi


Ugly work-around, but I have only a handful of users that should be
connecting to DMZ servers anyway and that fixed the problem.

Thanks a lot!

Regards,
Eri Ramos Bastos

On Mon, Aug 16, 2010 at 3:07 PM, Daniel Morrison <draker at gmail.com> wrote:
> Hi,
>
> 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:
>
> DisplayManager.DISPLAY.userAuthDir
> 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:
>
> http://www.sunmanagers.org/pipermail/sunmanagers/2005-March/035223.html
>
> but there is no answer.
>
> I found this page:
>
> http://www.sprint.net.au/~terbut/usefulbox/svrxlinux.htm
>
> 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:
>
> http://lists.mindrot.org/pipermail/openssh-unix-dev/2001-July/007413.html
>
> "...[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
> directory)."
>
> 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
> directory?"
>
> 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...?
>
> -D.
>
> 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
> _______________________________________________
> nSLUG mailing list
> nSLUG at nslug.ns.ca
> http://nslug.ns.ca/mailman/listinfo/nslug
>



More information about the nSLUG mailing list