[nSLUG] .Xauthority and communal directory

Daniel Morrison draker at gmail.com
Tue Aug 17 12:57:49 ADT 2010


Hi,

That presumes that /home is world-writable, which seems a risk.
(writable implies readable, and removable). But it's a quick solution.
If it works for you -- perhaps a note in the motd would suffice,
warning users that files should not be stored on this system, and any
confidential data should not even be brought over.

-D.

On 17 August 2010 12:10, Eri Ramos Bastos <bastos.eri at gmail.com> wrote:
> 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
>>
> _______________________________________________
> nSLUG mailing list
> nSLUG at nslug.ns.ca
> http://nslug.ns.ca/mailman/listinfo/nslug
>



More information about the nSLUG mailing list