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

Close

#2419 send and xauth problem on Fedora 8

obsolete: 8.5.1
closed-fixed
58. [send] (22)
5
2009-08-25
2008-03-08
No

[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.

Discussion

  • 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
    SI:localuser:hans

    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