disable xauth for local users

[Alexander Sack]

[Impact]
In the Karmic release, this fix was dropped accidentally. This causes a regression for people who do new installations, which makes xauth required again even for local users. It does not affect upgraders since earlier versions of the package installed it and no versions actually remove it so the file would still be in place.

[Development Fix]
The fix has been committed to xorg git and will be made available when we next update xorg in Lucid.

[Release Fix]
The debdiff attached to this bug restores the file.

[Regression Potential]
Essentially none. This file had been present up until very shortly before karmic released with no ill effect. This change does nothing more than restore the file.

Binary package hint: xorg

recent NetworkManager upgrade reveals that X sessions cannot deal with a changed hostname. Further investigation showed that fedora and opensuse dont have this issue.

http://mail.gnome.org/archives/networkmanager-list/2008-September/msg00291.html

In order to prepare ubuntu intrepid for NM 0.7 we should consider to apply http://cvs.fedoraproject.org/viewvc/rpms/xorg-x11-xinit/devel/localuser.sh?revision=1.2&view=markup to your Xsessions.d

[Alexander Sack (asac)]

milestoning for final as not fixing this will require us to strip down NetworkManager features and will leave NetworkManager svn builds completely unsupported (in that it breaks your X session).

[Alexander Sack (asac)]

to avoid confusion and unneeded discussion: the default NM install on ubuntu will honour /etc/hostname. This bug is just about those that opt-out and explicitly want to get the hostname updated.

[Alexander Sack (asac)]

AIUI, network-manager will not do these automatic hostname updates anymore.

Dropping milestone to reflect the reduced severity. Anyway, still something we should consider imo.

[Alexander Sack (asac)]

On Thu, Oct 16, 2008 at 06:24:24PM -0000, Bryce Harrington wrote:
> ** Changed in: xorg (Ubuntu Intrepid)
> Status: Triaged => Won't Fix
>

Bryce, wont fix because of lack of time or because of technical
reasons not to do what redhat and most likely suse do?

 - Alexander

[Oliver Grawert (ogra)]

well, a saner way would probably be to just add the "new" host to the xauthority file instead of dropping all security checking

[Alexander Sack (asac)]

On Mon, Oct 20, 2008 at 12:20:31AM -0000, Oliver Grawert wrote:
> well, a saner way would probably be to just add the "new" host to the
> xauthority file instead of dropping all security checking
>

Right, but if the security checkings have no use, then we should drop
them for localusers. If there is a use we should get a fix for this
upstream.

redhat appears to be convinced that there is no reason for this
security for local users. do we have reason to believe that thats
wrong?

 - Alexander

[Bryce Harrington (bryce)]

> Bryce, wont fix because of lack of time or because of technical
> reasons not to do what redhat and most likely suse do?

Primarily because you had already identified a workaround. I don't have a problem with it technically and am happy to include it, but we need to get the security team's buy-off on it. I'll sub Kees to it for review.

[Kees Cook (kees)]

I don't have any objection to this. It seems safe if it actually works as documented. :)
Note the caveat from the end of "man Xsecurity":

              If your system supports [localuser] and you use it, be warned
              that some programs that proxy connections and are setuid or set‐
              gid may get authenticated as the uid or gid of the proxy pro‐
              cess. For instance, some versions of ssh will be authenticated
              as the user root, no matter what user is running the ssh client,
              so on systems with such software, adding access for
              localuser:root may allow wider access than intended to the X
              display.

As such, it should probably be tested with things that are known to do funny uid things, like the PolicyKit password helpers, etc. As long as those still work when the hostname changes, this seems like a reasonable addition.

[Oliver Grawert (ogra)]

please note that ltsp (which we promote as a product) by default uses ssh -Y as connection method (with proxied X connection as described above) and offers an additional feature to do teh X traffic forwarding unencrypted (while keeping teh password handshake in a ssh tunnel) that is secured by xauth cookies. LDM (the ltsp display manager) uses functionallity to add and remove on the fly generated session cookies to the Xauthority file of the user for the latter case, i dont see why this shouldnt just work in case of a hostname change.

[Alexander Sack (asac)]

On Mon, Nov 10, 2008 at 10:06:05AM -0000, Oliver Grawert wrote:
> please note that ltsp (which we promote as a product) by default uses
> ssh -Y as connection method (with proxied X connection as described
> above) and offers an additional feature to do teh X traffic forwarding
> unencrypted (while keeping teh password handshake in a ssh tunnel) that
> is secured by xauth cookies. LDM (the ltsp display manager) uses
> functionallity to add and remove on the fly generated session cookies to
> the Xauthority file of the user for the latter case, i dont see why this
> shouldnt just work in case of a hostname change.
>

This is valid for complex setups but imo, we should not go for such
complicated solutions if there is a simple one for almost all cases -
and which is used by fedora.

Bryce, can you push this to jaunty please?

 - Alexander

[Alexander Sack (asac)]

On Wed, Feb 11, 2009 at 11:52:35PM -0000, Bryce Harrington wrote:
> ** Changed in: xorg (Ubuntu)
> Importance: Medium => High
> Assignee: (unassigned) => Bryce Harrington (bryceharrington)
>

thanks for taking a look at this bryce. This would be helpful to have
i think.

 - Alexander

[Bryce Harrington (bryce)]

Btw, can you test if just running the localhost.sh script is sufficient to solve the issue? I'm wondering if the "-nolisten tcp" option also needs to be removed in order to make xhost work properly. Hopefully it isn't, but please confirm.

[Bryce Harrington (bryce)]

Here's what I've got queued to commit - would you mind reviewing this and making sure it includes everything needed? Thanks ahead of time.

[Launchpad Janitor (janitor)]

This bug was fixed in the package xorg - 1:7.4~5ubuntu14

---------------
xorg (1:7.4~5ubuntu14) jaunty; urgency=low

  * Add local/Xsession.d/60x11-localhost: Allow X connections from local
    unix domain sockets instead of forcing TCP since hostname validation
    is not necessary in this case.
    (LP: #276357)
  * apport/source_xorg.py: Detect presence of fglrx loaded in kernel

 -- Bryce Harrington <email address hidden> Tue, 10 Mar 2009 09:56:15 -0700

[Gerhard Zlabinger (gerhard-zlabinger)]

After upgrading to version 1:7.4~5ubuntu14, I cannot login anymore. ~/.xsession-errors says

/etc/gdm/Xsession: Beginning session setup...
/etc/X11/Xsession.d/60x11-localhost: 4: Syntax error: Bad fd number

[JIm Purdy (jim-purdy-comcast)]

I've got the same exact problem!

/etc/gdm/Xsession: Beginning session setup...
/etc/X11/Xsession.d/60x11-localhost: 4: Syntax error: Bad fd number

[Gerhard Zlabinger (gerhard-zlabinger)]

Error is fixed in version 1:7.4~5ubuntu15.

[luvinit (markkeeling)]

It seems I have a related problem with Jaunty Jackalope.
I am trying LTSP on Jaunty. The reason that I am trying Jaunty is because there were also other errors in Gnome that stopped the Hardy and Intrepid versions from allowing login, but those errors seem to have gone in the Jaunty verison, but I still can't login. Originally I couldn't login to the client, no errors were listed in the .xsession-errors file. Two days ago there were updates to the LTSP and other packages and LTSP worked for all of one day. Now I can no longer login, but the difference is that there is the following error listed:
Xsession: X session started for ltsp at Thu Mar 12 11:22:30 GMT 2009
*xhost: must be on local machine to add or remove hosts.*
Setting IM through im-switch for locale=en_GB.
Start IM through /etc/X11/xinit/xinput.d/all_ALL linked to /etc/X11/xinit/xinput.d/default.
I: caps.c: Limited capabilities successfully to CAP_SYS_NICE.
I: caps.c: Dropping root privileges.
I: caps.c: Limited capabilities successfully to CAP_SYS_NICE.
Failure: Module initalization failed

I have the 1:7.4~5ubuntu15 xorg package mentioned above installed on the system.

[Bryce Harrington (bryce)]

luvinit, that sounds like a separate issue; it won't get investigated on this bug report so if you'd like to have it looked at, report it as a new bug.

[Oliver Grawert (ogra)]

bryce, it was me who duplicated the original ltsp bug, there were no changes in ltsp and the problem showed exactly after your change in Xorg (note that we keep the X authentication for LTSP on the thin client (since thats where the X server runs in LTSP, with no write access to xauth data from the server)) if the xauth changes are done by an Xsession.d script you wont be able to write to the actual authentication file in use, probably the script needs special casing if LTSP_CLIENT is set (having this in the environment is the case on a ltsp clients) and just skip setting local cookies...

[Bryce Harrington (bryce)]

I'm reopening this bug because it regressed. Due to bug 340807 the file got renamed, but this didn't get into git apparently, and got dropped as a stray file. I probably didn't have enough coffee that day. The attached debdiff restores it.

[Bryce Harrington (bryce)]

Here is the file in question, in case anyone needs it to work around the problem while this SRU goes through the process. Copy this to /etc/X11/Xsession.d/

[Martin Pitt (pitti)]

Bryce, please go ahead and upload. (Don't wait for acks before uploading; we can still reject the upload if it's wrong)

[Bryce Harrington (bryce)]

Okay, done

On Tue, Nov 03, 2009 at 11:44:56PM -0000, Martin Pitt wrote:
> Bryce, please go ahead and upload. (Don't wait for acks before
> uploading; we can still reject the upload if it's wrong)
>
> --
> disable xauth for local users
> https://bugs.launchpad.net/bugs/276357
> You received this bug notification because you are a bug assignee.
>
> Status in ???xorg??? package in Ubuntu: Fix Committed
> Status in xorg in Ubuntu Lucid: Fix Committed
> Status in xorg in Ubuntu Intrepid: Won't Fix
> Status in xorg in Ubuntu Karmic: In Progress
>
> Bug description:
> [Impact]
> In the Karmic release, this fix was dropped accidentally. This causes a regression for people who do new installations, which makes xauth required again even for local users. It does not affect upgraders since earlier versions of the package installed it and no versions actually remove it so the file would still be in place.
>
> [Development Fix]
> The fix has been committed to xorg git and will be made available when we next update xorg in Lucid.
>
> [Release Fix]
> The debdiff attached to this bug restores the file.
>
> [Regression Potential]
> Essentially none. This file had been present up until very shortly before karmic released with no ill effect. This change does nothing more than restore the file.
>
> Binary package hint: xorg
>
> recent NetworkManager upgrade reveals that X sessions cannot deal with a changed hostname. Further investigation showed that fedora and opensuse dont have this issue.
>
> http://mail.gnome.org/archives/networkmanager-list/2008-September/msg00291.html
>
> In order to prepare ubuntu intrepid for NM 0.7 we should consider to apply http://cvs.fedoraproject.org/viewvc/rpms/xorg-x11-xinit/devel/localuser.sh?revision=1.2&view=markup to your Xsessions.d
>

[Timo Aaltonen (tjaalton)]

lucid is now fixed.

[lunkwill (launchpad-lunkwill)]

This affected me in karmic, but after a dist-upgrade it now works. Changing to "Fix released"