Re: [gdm-list] Why do GDM 2.22.0 set xauth file owner as login user

[Brian Cameron <Brian Cameron Sun COM>]

Ray:

> The advantage is something like "I have an nfs mounted home directory
> and i want immediate access to all X displays that are currently
> logged in"
>
> But this advantage isn't real.
>
> 1) we don't really support logging in more than once with the same
> home directory anyway in gnome (although i've recently commited some
> patches to bonobo and gconf to help this)

Although GNOME is one desktop that you can start via the display
manager, we can't really assume it will be the only one, or that
other desktop sessions have the same issues.

> 2) it requires all the displays listening for tcp connections and not
> be firewalled off
> 3) it means things go over the wire in the clear.

This makes sense to me.  Also, personally, I agree that it probably
makes sense to avoid the problems with doing things this way.

For example, I suspect GDM would behave badly if a user is setting
the XAUTHORITY value to something they expect should work, and
stomping the value set by GDM, causing possible problems for users
who upgrade to the new GDM.

> The modern day answer to this is "ssh -Y" which generates it's own,
> cookie and moves X traffic through a tunnel.
>
> The problems it causes are with root squashing nfs home directories,
> encrypted home directories, pam_mkhomedir etc.

Even still, there are probably users who still do things the old way
who might be irritated if GDM stops working for them.  I agree that
disabling such features by default for better security is sensible,
but some users will likely be irritated if they can't configure
the system to do what they want.

> The old gdm had an "unbreak me" options like NeverPlaceCookiesOnNFS
> and  the pair (UserAuthDir="" ,  UserAuthFBDir="/tmp") to work around
> the problems.
>
> Note, the XAUTHORITY environment variable is set to the correct
> location of the auth cookies, so anything that needs access to the
> cookie should be able to find it.

Unless the user sets (or wants to set) XAUTHORITY to something else for
some reason.

> Is this breaking something for you guys?  If so, maybe we can figure
> out a fix together.

No, it's not breaking anything.  I was just surprised when I realized
GDM is working this way.  If we think there are good reasons to change
this, and if we're prepared for dealing with the users who might
disagree, then I don't have a problem.

> What do you mean by "honor the user's file" ? We control where the
> user's file is via the XAUTHORITY environment variable.  GDM isn't a
> consumer of the X authority file, it's the producer.

I thought the way GDM worked was that if the user already had an
XAUTHORITY file (e.g. $HOME/.Xauthority), that GDM tried to honor it
and use it instead of creating a new cookie.  Isn't this needed to
support the feature you speak above of sharing the same token
across desktops?

> Note also, we aren't loosening any permissions.  GDM's auth cookie
> file is only readable by it.

1773 or 1775 is more loose than 1770, though I agree this loosening is
probably not worth any serious concern.

Brian