Learn how easy it is to sync an existing GitHub or Google Code repo to a SourceForge project! See Demo


#2419 send and xauth problem on Fedora 8

obsolete: 8.5.1
58. [send] (22)

[send] doesn't work on Fedora 8 with stock setup due to the auth setup checks [send] does.

There was a bug filed against Fedora regarding this issue: https://bugzilla.redhat.com/show_bug.cgi?id=349071 which was closed with the resolution "not a bug" and the explanation attached from which it's clear that Fedora is not about changing its policy regarding X auth setup. This implies [send] will continue not to work properly on future versions of Fedora (and who knows -- may be RHEL also).

I'm not an expert in X auth so it would be cool if someone with enough expertise in this field analyzed the situation -- may be [send] worth fixing to lax its rules regarding checking of X auth settings or so.


  • I am also afflicted by this issue on Ubuntu 9.04 Jaunty. When I run a 'send', I get:
    X server insecure (must use xauth-style authorization); command ignored

    When I run xhost, I get:
    access control enabled, only authorized clients can connect

    It seems that Fedora and Ubuntu are using this as their default setup, with Fedora claiming that they are going to stop using xauth: https://bugzilla.redhat.com/show_bug.cgi?id=349071#c2

  • Here's a relevant bit of conversation from #tcl with identities removed:

    (06:41:03 PM) <#1> SI: in an xhost list means something specific; It means "If I can do getpeereid or getpeerucred, then I can actually make sure that the remote user is who he says he is.
    (06:41:46 PM) <#1> And so xhost +SI:* possibly shouldn't cause Tk to mark itself as insecure - it limits to local connections and looks up who's at the other end of the socket.
    (06:42:16 PM) <#3> hmm. So they've actually improved xhost-safety, then?
    (06:42:16 PM) <#0> yeah, it seems that there would just need to be an xhost exception for that single case
    (06:42:39 PM) <#3> Then perhaps it would warrant a Feature Request to enhance [send] to understand that.
    (06:42:42 PM) <#0> #3: I imagine so, if they are building their system around it
    (06:42:46 PM) <#3> Calling it a bug is still wrong, though.
    (06:42:56 PM) <#1> Also the krb: (Kerberos) and nis: (Secure RPC) cases.
    (06:43:44 PM) <#1> And such a Feature Request, on the surface of it, makes sense. In fact, it makes enough sense that there might be an argument in favour of calling it a Bug.
    (06:44:01 PM) #0: seems like the thing to do is change the Tk bug report to a feature request, and put this info there
    (06:44:10 PM) <#1> http://www.x.org/archive/X11R6.8.1/doc/xhost.1.html
    (06:46:18 PM) <#1> Actually, the nis: family might be going too far - but that's back to "why are you using that stuff, anyway?"
    (06:50:37 PM) <#1> And SI would have to restrict to SI:localuser and SI:localgroup, becase SI:hostname and SI:IPv6 are going to be intrinsically insecure

  • Ah! I see what they're doing. (Ye gods! This is documented badly...)

    Fixed in HEAD and 8.5 branch. Note that Tk will only support this if the X includes define FamilyServerInterpreted; not all deployments do yet (e.g., this OSX box doesn't).

    • assigned_to: caflick --> dkf
    • status: open --> closed-fixed