[nSLUG] .Xauthority and communal directory
Eri Ramos Bastos
bastos.eri at gmail.com
Tue Aug 17 13:27:58 ADT 2010
Yes, but hopefully the only reason why someone should log in those
servers is to troubleshoot something (and therefore run the script
that require X) and nothing else.
And only some specific groups should have access to those boxes, which
make easier to keep track of what's going on.
The login script looks like this, in case someone has a similar requirement:
On Tue, Aug 17, 2010 at 12:57 PM, Daniel Morrison <draker at gmail.com> wrote:
> 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.
> 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" ]
>> mkdir -p $HOME
>> echo "Your session needs to be restarted. Please log in again"
>> sleep 2
>> 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!
>> Eri Ramos Bastos
>> On Mon, Aug 16, 2010 at 3:07 PM, Daniel Morrison <draker at gmail.com> wrote:
>>> 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.
>>> nSLUG mailing list
>>> nSLUG at nslug.ns.ca
>> nSLUG mailing list
>> nSLUG at nslug.ns.ca
> nSLUG mailing list
> nSLUG at nslug.ns.ca
More information about the nSLUG