From: David A. V. <ven...@ms...> - 2009-11-16 23:04:33
|
Hello, When I try to use the Tk driver, I get the error "X server insecure", which is pasted into the email below. How do I get around this? This is on Ubuntu Linux 9.10 "Karmic Koala", a Debian-package managed system. When I search for this error in Google, I find this wiki.tcl.tk page that was last updated in 2003: http://wiki.tcl.tk/1829 There's some finger-wagging about insecure systems, and then it seems to recommend doing some minor surgery, removing hosts using this script: #!/bin/sh for host in 'xhost | sed 1d' ; do echo removing $host from access control list xhost -$host done echo removing general access from access control list xhost - While that works, it seems a little strange that I have to do this just to run a Tcl/Tk application, and it gives me pause if I consider building an "Extended WISH" that uses Tk, as described in the PLplot documentation. What does the PLplot community recommend in this situation? All the best, David ------- begin paste -------- Enter device number or keyword: 2 X server insecure (must use xauth-style authorization); command ignored while executing "send $client "set server_name [list $server_name]"" (procedure "plserver_link_init" line 25) invoked from within "plserver_link_init" (procedure "plserver_init" line 85) invoked from within "plserver_init" -- David A. Ventimiglia <ven...@ms...> Michigan State University |
From: Alan W. I. <ir...@be...> - 2009-11-17 01:16:51
|
On 2009-11-16 18:04-0500 David A. Ventimiglia wrote: > Hello, > > When I try to use the Tk driver, I get the error "X server insecure", > which is pasted into the email below. How do I get around this? This > is on Ubuntu Linux 9.10 "Karmic Koala", a Debian-package managed system. > When I search for this error in Google, I find this wiki.tcl.tk page > that was last updated in 2003: > > http://wiki.tcl.tk/1829 > > There's some finger-wagging about insecure systems, and then it seems to > recommend doing some minor surgery, removing hosts using this script: > > #!/bin/sh > for host in 'xhost | sed 1d' ; do > echo removing $host from access control list > xhost -$host > done > echo removing general access from access control list > xhost - > > > While that works, it seems a little strange that I have to do this just > to run a Tcl/Tk application, and it gives me pause if I consider > building an "Extended WISH" that uses Tk, as described in the PLplot > documentation. > > What does the PLplot community recommend in this situation? Hi David: Good question. "man xhost" says it implements rudimentary X security. Of course, that is only the case if you use xhost to turn off all access (other than your own) which the above script appears to do. Because running the above script on Ubuntu karmic apparently makes a difference, that means karmic has configured xhost by default in a way that is blatently insecure (at least if there is any network access to your system). The above script makes no difference on my own Debian stable system, i.e., access control is turned on. I don't recall fiddling with xhost (before today) so I think this actually happened during Debian stable installation, and I am surprised that apparently is not the case for Ubuntu karmic. Anyhow, I am glad for your sake that you discovered the Ubuntu karmic xhost security hole via your use of the PLplot Tk driver. At least now you have some rudimentary X security via the above script. Alan __________________________ Alan W. Irwin Astronomical research affiliation with Department of Physics and Astronomy, University of Victoria (astrowww.phys.uvic.ca). Programming affiliations with the FreeEOS equation-of-state implementation for stellar interiors (freeeos.sf.net); PLplot scientific plotting software package (plplot.org); the libLASi project (unifont.org/lasi); the Loads of Linux Links project (loll.sf.net); and the Linux Brochure Project (lbproject.sf.net). __________________________ Linux-powered Science __________________________ |
From: David A. V. <ven...@ms...> - 2009-11-17 01:29:27
|
Hi Alan, Thanks for the reply. I'm sorry, but I don't really understand X Windows security or the lack thereof, so I'll have to spend some time grokking this xhost business. :) In any event, it sounds like what you're saying is that this error is not a problem with Tcl, Tk, or PLplot, but rather a legitimate security hole that is either uncommon or doesn't exist at all on other Linux distros, but evidently does exist in Ubuntu Karmic Koala (at least, it does on my machine...I wonder what would happen if I'd done a clean install instead of an upgrade from Jaunty Jaguar). Is that correct? In that case, I suppose my queries should be redirected at the Ubuntu maintainers. :) All the best, David On Mon, 2009-11-16 at 17:16 -0800, Alan W. Irwin wrote: > On 2009-11-16 18:04-0500 David A. Ventimiglia wrote: > > > Hello, > > > > When I try to use the Tk driver, I get the error "X server insecure", > > which is pasted into the email below. How do I get around this? This > > is on Ubuntu Linux 9.10 "Karmic Koala", a Debian-package managed system. > > When I search for this error in Google, I find this wiki.tcl.tk page > > that was last updated in 2003: > > > > http://wiki.tcl.tk/1829 > > > > There's some finger-wagging about insecure systems, and then it seems to > > recommend doing some minor surgery, removing hosts using this script: > > > > #!/bin/sh > > for host in 'xhost | sed 1d' ; do > > echo removing $host from access control list > > xhost -$host > > done > > echo removing general access from access control list > > xhost - > > > > > > While that works, it seems a little strange that I have to do this just > > to run a Tcl/Tk application, and it gives me pause if I consider > > building an "Extended WISH" that uses Tk, as described in the PLplot > > documentation. > > > > What does the PLplot community recommend in this situation? > > Hi David: > > Good question. > > "man xhost" says it implements rudimentary X security. Of course, that is > only the case if you use xhost to turn off all access (other than your own) > which the above script appears to do. Because running the above script on > Ubuntu karmic apparently makes a difference, that means karmic has > configured xhost by default in a way that is blatently insecure (at least if > there is any network access to your system). > > The above script makes no difference on my own Debian stable system, i.e., > access control is turned on. I don't recall fiddling with xhost (before > today) so I think this actually happened during Debian stable installation, > and I am surprised that apparently is not the case for Ubuntu karmic. > > Anyhow, I am glad for your sake that you discovered the Ubuntu karmic xhost > security hole via your use of the PLplot Tk driver. At least now you have > some rudimentary X security via the above script. > > Alan > __________________________ > Alan W. Irwin > > Astronomical research affiliation with Department of Physics and Astronomy, > University of Victoria (astrowww.phys.uvic.ca). > > Programming affiliations with the FreeEOS equation-of-state implementation > for stellar interiors (freeeos.sf.net); PLplot scientific plotting software > package (plplot.org); the libLASi project (unifont.org/lasi); the Loads of > Linux Links project (loll.sf.net); and the Linux Brochure Project > (lbproject.sf.net). > __________________________ > > Linux-powered Science > __________________________ > -- David A. Ventimiglia <ven...@ms...> Michigan State University |
From: Alan W. I. <ir...@be...> - 2009-11-17 04:51:22
|
On 2009-11-16 20:29-0500 David A. Ventimiglia wrote: > Hi Alan, > > Thanks for the reply. I'm sorry, but I don't really understand X > Windows security or the lack thereof, so I'll have to spend some time > grokking this xhost business. :) In any event, it sounds like what > you're saying is that this error is not a problem with Tcl, Tk, or > PLplot, but rather a legitimate security hole that is either uncommon or > doesn't exist at all on other Linux distros, but evidently does exist in > Ubuntu Karmic Koala (at least, it does on my machine...I wonder what > would happen if I'd done a clean install instead of an upgrade from > Jaunty Jaguar). Is that correct? In that case, I suppose my queries > should be redirected at the Ubuntu maintainers. :) Yes, and yes. :-) Alan __________________________ Alan W. Irwin Astronomical research affiliation with Department of Physics and Astronomy, University of Victoria (astrowww.phys.uvic.ca). Programming affiliations with the FreeEOS equation-of-state implementation for stellar interiors (freeeos.sf.net); PLplot scientific plotting software package (plplot.org); the libLASi project (unifont.org/lasi); the Loads of Linux Links project (loll.sf.net); and the Linux Brochure Project (lbproject.sf.net). __________________________ Linux-powered Science __________________________ |
From: Arjen M. <arj...@de...> - 2009-11-17 07:54:22
|
On 2009-11-17 05:51, Alan W. Irwin wrote: > On 2009-11-16 20:29-0500 David A. Ventimiglia wrote: > >> Hi Alan, >> >> Thanks for the reply. I'm sorry, but I don't really understand X >> Windows security or the lack thereof, so I'll have to spend some time >> grokking this xhost business. :) In any event, it sounds like what >> you're saying is that this error is not a problem with Tcl, Tk, or >> PLplot, but rather a legitimate security hole that is either uncommon or >> doesn't exist at all on other Linux distros, but evidently does exist in >> Ubuntu Karmic Koala (at least, it does on my machine...I wonder what >> would happen if I'd done a clean install instead of an upgrade from >> Jaunty Jaguar). Is that correct? In that case, I suppose my queries >> should be redirected at the Ubuntu maintainers. :) > > Yes, and yes. :-) > I can add some further information on the issue (from the man page of the Tcl/Tk send command): The send command is potentially a serious security loophole. On Unix, any application that can connect to your X server can send scripts to your applications. These incoming scripts can use Tcl to read and write your files and invoke subprocesses under your name. Host-based access control such as that provided by xhost is particularly insecure, since it allows anyone with an account on particular hosts to connect to your server, and if disabled it allows anyone anywhere to connect to your server. In order to provide at least a small amount of security, Tk checks the access control being used by the server and rejects incoming sends unless (a) xhost-style access control is enabled (i.e. only certain hosts can establish connections) and (b) the list of enabled hosts is empty. This means that applications cannot connect to your server unless they use some other form of authorization such as that provide by xauth. Under Windows, send is currently disabled. Most of the functionality is provided by the dde command instead. IIRC, Tcl/Tk can be compiled with a flag that turns off this security check, but I do not think that is a wise thing to do. Regards, Arjen |
From: Andrew R. <and...@us...> - 2009-11-17 09:37:06
|
On Tue, Nov 17, 2009 at 08:54:09AM +0100, Arjen Markus wrote: > > > On 2009-11-17 05:51, Alan W. Irwin wrote: > > On 2009-11-16 20:29-0500 David A. Ventimiglia wrote: > > > >> Hi Alan, > >> > >> Thanks for the reply. I'm sorry, but I don't really understand X > >> Windows security or the lack thereof, so I'll have to spend some time > >> grokking this xhost business. :) In any event, it sounds like what > >> you're saying is that this error is not a problem with Tcl, Tk, or > >> PLplot, but rather a legitimate security hole that is either uncommon or > >> doesn't exist at all on other Linux distros, but evidently does exist in > >> Ubuntu Karmic Koala (at least, it does on my machine...I wonder what > >> would happen if I'd done a clean install instead of an upgrade from > >> Jaunty Jaguar). Is that correct? In that case, I suppose my queries > >> should be redirected at the Ubuntu maintainers. :) > > > > Yes, and yes. :-) > > > > I can add some further information on the issue (from the man page of > the Tcl/Tk send command): > > The send command is potentially a serious security loophole. On Unix, > any application that can connect to your X server can send scripts to > your applications. These incoming scripts can use Tcl to read and write > your files and invoke subprocesses under your name. Host-based access > control such as that provided by xhost is particularly insecure, since > it allows anyone with an account on particular hosts to connect to your > server, and if disabled it allows anyone anywhere to connect to your > server. In order to provide at least a small amount of security, Tk > checks the access control being used by the server and rejects incoming > sends unless (a) xhost-style access control is enabled (i.e. only > certain hosts can establish connections) and (b) the list of enabled > hosts is empty. This means that applications cannot connect to your > server unless they use some other form of authorization such as that > provide by xauth. Under Windows, send is currently disabled. Most of the > functionality is provided by the dde command instead. > > IIRC, Tcl/Tk can be compiled with a flag that turns off this security > check, but I do not think that is a wise thing to do. Just to comment further, this issue has been around with Ubuntu (maybe also Debian?) for a while. It is not a security issue. The default ubuntu setup has xhost +SI:localuser:<username>, where username is the user logged on. This allows the local user to display on the server - in particular it means that x programs started via sudo will correctly display. You can disable this, but then things like the package manager which need to run as root won't work. I don't think this particular use of xhost is a security issue, but tk is not that discriminating. The best course is probably to file a bug against the tk package in Ubuntu. By default you would expect it to work... The best solution would be a patch to tcl / tk to allow the localuser case. Regards Andrew |
From: Arjen M. <arj...@de...> - 2009-11-17 10:29:30
|
Hi Andrew, as I know too little about xhost and security issues to really comment on your comment, I have posted the matter on comp.lang.tcl. Let us see what comes out of that. Regards, Arjen > > Just to comment further, this issue has been around with Ubuntu (maybe also > Debian?) for a while. It is not a security issue. The default ubuntu setup > has xhost +SI:localuser:<username>, where username is the user logged on. > This allows the local user to display on the server - in particular it means > that x programs started via sudo will correctly display. You can disable > this, but then things like the package manager which need to run as root > won't work. I don't think this particular use of xhost is a security issue, > but tk is not that discriminating. The best course is probably to file a > bug against the tk package in Ubuntu. By default you would expect it to > work... The best solution would be a patch to tcl / tk to allow the localuser > case. > |
From: Alan W. I. <ir...@be...> - 2009-11-17 18:29:55
|
On 2009-11-17 09:36-0000 Andrew Ross wrote: > On Tue, Nov 17, 2009 at 08:54:09AM +0100, Arjen Markus wrote: >> >> >> On 2009-11-17 05:51, Alan W. Irwin wrote: >>> On 2009-11-16 20:29-0500 David A. Ventimiglia wrote: >>> >>>> Hi Alan, >>>> >>>> Thanks for the reply. I'm sorry, but I don't really understand X >>>> Windows security or the lack thereof, so I'll have to spend some time >>>> grokking this xhost business. :) In any event, it sounds like what >>>> you're saying is that this error is not a problem with Tcl, Tk, or >>>> PLplot, but rather a legitimate security hole that is either uncommon or >>>> doesn't exist at all on other Linux distros, but evidently does exist in >>>> Ubuntu Karmic Koala (at least, it does on my machine...I wonder what >>>> would happen if I'd done a clean install instead of an upgrade from >>>> Jaunty Jaguar). Is that correct? In that case, I suppose my queries >>>> should be redirected at the Ubuntu maintainers. :) >>> >>> Yes, and yes. :-) >>> >> >> I can add some further information on the issue (from the man page of >> the Tcl/Tk send command): >> >> The send command is potentially a serious security loophole. On Unix, >> any application that can connect to your X server can send scripts to >> your applications. These incoming scripts can use Tcl to read and write >> your files and invoke subprocesses under your name. Host-based access >> control such as that provided by xhost is particularly insecure, since >> it allows anyone with an account on particular hosts to connect to your >> server, and if disabled it allows anyone anywhere to connect to your >> server. In order to provide at least a small amount of security, Tk >> checks the access control being used by the server and rejects incoming >> sends unless (a) xhost-style access control is enabled (i.e. only >> certain hosts can establish connections) and (b) the list of enabled >> hosts is empty. This means that applications cannot connect to your >> server unless they use some other form of authorization such as that >> provide by xauth. Under Windows, send is currently disabled. Most of the >> functionality is provided by the dde command instead. >> >> IIRC, Tcl/Tk can be compiled with a flag that turns off this security >> check, but I do not think that is a wise thing to do. > > Just to comment further, this issue has been around with Ubuntu (maybe also > Debian?) for a while. It is not a security issue. The default ubuntu setup > has xhost +SI:localuser:<username>, where username is the user logged on. > This allows the local user to display on the server - in particular it means > that x programs started via sudo will correctly display. You can disable > this, but then things like the package manager which need to run as root > won't work. I don't think this particular use of xhost is a security issue, > but tk is not that discriminating. The best course is probably to file a > bug against the tk package in Ubuntu. By default you would expect it to > work... The best solution would be a patch to tcl / tk to allow the localuser > case. Thanks, Andrew, for that further explanation of the Ubuntu xhost default. I am positive Debian doesn't do it that way by default (perhaps there is no need since they tend not to emphasize sudo like Ubuntu does), but it does sound like xhost +SI:localuser:<username> is an example of one of the few xhost +* combinations that is secure, and Ubuntu might need to patch Tcl/Tk accordingly to accept that. However, that explanation may be too easy and Ubuntu may have done that already. For example, my understanding is you do run Ubuntu and you do test Tcl/Tk, and apparently the above "xhost +*" combination is set for your case. So I am wondering why you haven't run into this problem yourself? If you cannot reproduce this issue with any of your Ubuntu platforms, then perhaps this user has some older Tcl/Tk installed that is not really compatible with Karmic, and in that case, the solution for him might be to simply purge Tcl/Tk and reinstall the version of Tcl/Tk that comes with Karmic (which is more likely to be compatible with how Karmic handles xhost). Alan __________________________ Alan W. Irwin Astronomical research affiliation with Department of Physics and Astronomy, University of Victoria (astrowww.phys.uvic.ca). Programming affiliations with the FreeEOS equation-of-state implementation for stellar interiors (freeeos.sf.net); PLplot scientific plotting software package (plplot.org); the libLASi project (unifont.org/lasi); the Loads of Linux Links project (loll.sf.net); and the Linux Brochure Project (lbproject.sf.net). __________________________ Linux-powered Science __________________________ |
From: Andrew R. <and...@us...> - 2009-11-17 19:33:49
|
On Tue, Nov 17, 2009 at 10:29:45AM -0800, Alan Irwin wrote: > On 2009-11-17 09:36-0000 Andrew Ross wrote: > >> On Tue, Nov 17, 2009 at 08:54:09AM +0100, Arjen Markus wrote: >>> >>> >>> On 2009-11-17 05:51, Alan W. Irwin wrote: >>>> On 2009-11-16 20:29-0500 David A. Ventimiglia wrote: >>>> >>>>> Hi Alan, >>>>> >>>>> Thanks for the reply. I'm sorry, but I don't really understand X >>>>> Windows security or the lack thereof, so I'll have to spend some time >>>>> grokking this xhost business. :) In any event, it sounds like what >>>>> you're saying is that this error is not a problem with Tcl, Tk, or >>>>> PLplot, but rather a legitimate security hole that is either uncommon or >>>>> doesn't exist at all on other Linux distros, but evidently does exist in >>>>> Ubuntu Karmic Koala (at least, it does on my machine...I wonder what >>>>> would happen if I'd done a clean install instead of an upgrade from >>>>> Jaunty Jaguar). Is that correct? In that case, I suppose my queries >>>>> should be redirected at the Ubuntu maintainers. :) >>>> >>>> Yes, and yes. :-) >>>> >>> >>> I can add some further information on the issue (from the man page of >>> the Tcl/Tk send command): >>> >>> The send command is potentially a serious security loophole. On Unix, >>> any application that can connect to your X server can send scripts to >>> your applications. These incoming scripts can use Tcl to read and write >>> your files and invoke subprocesses under your name. Host-based access >>> control such as that provided by xhost is particularly insecure, since >>> it allows anyone with an account on particular hosts to connect to your >>> server, and if disabled it allows anyone anywhere to connect to your >>> server. In order to provide at least a small amount of security, Tk >>> checks the access control being used by the server and rejects incoming >>> sends unless (a) xhost-style access control is enabled (i.e. only >>> certain hosts can establish connections) and (b) the list of enabled >>> hosts is empty. This means that applications cannot connect to your >>> server unless they use some other form of authorization such as that >>> provide by xauth. Under Windows, send is currently disabled. Most of the >>> functionality is provided by the dde command instead. >>> >>> IIRC, Tcl/Tk can be compiled with a flag that turns off this security >>> check, but I do not think that is a wise thing to do. >> >> Just to comment further, this issue has been around with Ubuntu (maybe also >> Debian?) for a while. It is not a security issue. The default ubuntu setup >> has xhost +SI:localuser:<username>, where username is the user logged on. >> This allows the local user to display on the server - in particular it means >> that x programs started via sudo will correctly display. You can disable >> this, but then things like the package manager which need to run as root >> won't work. I don't think this particular use of xhost is a security issue, >> but tk is not that discriminating. The best course is probably to file a >> bug against the tk package in Ubuntu. By default you would expect it to >> work... The best solution would be a patch to tcl / tk to allow the localuser >> case. > > Thanks, Andrew, for that further explanation of the Ubuntu xhost default. I > am positive Debian doesn't do it that way by default (perhaps there is no > need since they tend not to emphasize sudo like Ubuntu does), but it does > sound like > > xhost +SI:localuser:<username> > > is an example of one of the few xhost +* combinations that is secure, and > Ubuntu might need to patch Tcl/Tk accordingly to accept that. > > However, that explanation may be too easy and Ubuntu may have done that > already. For example, my understanding is you do run Ubuntu and you do test > Tcl/Tk, and apparently the above "xhost +*" combination is set for your > case. So I am wondering why you haven't run into this problem yourself? If > you cannot reproduce this issue with any of your Ubuntu platforms, then > perhaps this user has some older Tcl/Tk installed that is not really > compatible with Karmic, and in that case, the solution for him might be to > simply purge Tcl/Tk and reinstall the version of Tcl/Tk that comes with > Karmic (which is more likely to be compatible with how Karmic handles > xhost). This has been a longstanding issue for me with tk and Ubuntu, it's just I've silently worked around it by disabling xhost altogether when I need to test tk and plplot. I tend not to use tk regularly, and I also tend not to use the GUI admin tools so it is not too much of a pain for me. I'm glad to hear it is fixed upstream in tcl / tk though. Andrew |
From: David A. V. <ven...@ms...> - 2009-11-17 19:42:24
|
On Tue, 2009-11-17 at 10:29 -0800, Alan W. Irwin wrote: > On 2009-11-17 09:36-0000 Andrew Ross wrote: > > > On Tue, Nov 17, 2009 at 08:54:09AM +0100, Arjen Markus wrote: > >> > >> > >> On 2009-11-17 05:51, Alan W. Irwin wrote: > >>> On 2009-11-16 20:29-0500 David A. Ventimiglia wrote: > >>> > >>>> Hi Alan, > >>>> > >>>> Thanks for the reply. I'm sorry, but I don't really understand X > >>>> Windows security or the lack thereof, so I'll have to spend some time > >>>> grokking this xhost business. :) In any event, it sounds like what > >>>> you're saying is that this error is not a problem with Tcl, Tk, or > >>>> PLplot, but rather a legitimate security hole that is either uncommon or > >>>> doesn't exist at all on other Linux distros, but evidently does exist in > >>>> Ubuntu Karmic Koala (at least, it does on my machine...I wonder what > >>>> would happen if I'd done a clean install instead of an upgrade from > >>>> Jaunty Jaguar). Is that correct? In that case, I suppose my queries > >>>> should be redirected at the Ubuntu maintainers. :) > >>> > >>> Yes, and yes. :-) > >>> > >> > >> I can add some further information on the issue (from the man page of > >> the Tcl/Tk send command): > >> > >> The send command is potentially a serious security loophole. On Unix, > >> any application that can connect to your X server can send scripts to > >> your applications. These incoming scripts can use Tcl to read and write > >> your files and invoke subprocesses under your name. Host-based access > >> control such as that provided by xhost is particularly insecure, since > >> it allows anyone with an account on particular hosts to connect to your > >> server, and if disabled it allows anyone anywhere to connect to your > >> server. In order to provide at least a small amount of security, Tk > >> checks the access control being used by the server and rejects incoming > >> sends unless (a) xhost-style access control is enabled (i.e. only > >> certain hosts can establish connections) and (b) the list of enabled > >> hosts is empty. This means that applications cannot connect to your > >> server unless they use some other form of authorization such as that > >> provide by xauth. Under Windows, send is currently disabled. Most of the > >> functionality is provided by the dde command instead. > >> > >> IIRC, Tcl/Tk can be compiled with a flag that turns off this security > >> check, but I do not think that is a wise thing to do. > > > > Just to comment further, this issue has been around with Ubuntu (maybe also > > Debian?) for a while. It is not a security issue. The default ubuntu setup > > has xhost +SI:localuser:<username>, where username is the user logged on. > > This allows the local user to display on the server - in particular it means > > that x programs started via sudo will correctly display. You can disable > > this, but then things like the package manager which need to run as root > > won't work. I don't think this particular use of xhost is a security issue, > > but tk is not that discriminating. The best course is probably to file a > > bug against the tk package in Ubuntu. By default you would expect it to > > work... The best solution would be a patch to tcl / tk to allow the localuser > > case. > > Thanks, Andrew, for that further explanation of the Ubuntu xhost default. I > am positive Debian doesn't do it that way by default (perhaps there is no > need since they tend not to emphasize sudo like Ubuntu does), but it does > sound like > > xhost +SI:localuser:<username> > > is an example of one of the few xhost +* combinations that is secure, and > Ubuntu might need to patch Tcl/Tk accordingly to accept that. > > However, that explanation may be too easy and Ubuntu may have done that > already. For example, my understanding is you do run Ubuntu and you do test > Tcl/Tk, and apparently the above "xhost +*" combination is set for your > case. So I am wondering why you haven't run into this problem yourself? If > you cannot reproduce this issue with any of your Ubuntu platforms, then > perhaps this user has some older Tcl/Tk installed that is not really > compatible with Karmic, and in that case, the solution for him might be to > simply purge Tcl/Tk and reinstall the version of Tcl/Tk that comes with > Karmic (which is more likely to be compatible with how Karmic handles > xhost). Hello, it's "this user". :) I tried what you suggested, which is to purge/reinstall Tcl/Tk, and here's what I found. With just the Canonical ppa archives enabled (i.e., the standard ones when you install or upgrade to Karmic Koala), the PLplot available is 5.9.2-3, and it seems the plplot-tcl package is configured with dependencies on Tcl 8.4 and Tk 8.4, and not on Tcl/Tk 8.5. Whether I have Tcl/Tk 8.5 installed or not, if I uninstall Tcl/Tk 8.4, then plplot-tcl automatically uninstalls. And, if I reinstall plplot-tcl, Tcl/Tk 8.4 automatically reinstalls. So, if the latest versions of Tcl/Tk are 8.5, and if they've been patched in some way to allow the above xhost+ combination, but if Tcl/Tk 8.4 do not allow this combination, then it looks like the current packaging of plplot-tcl in the Canonical archives are just not current enough because it's still using Tcl/Tk 8.4. At least...I think. Or maybe not. :) So, modulo the understandable lag between the most recent version of software projects, and the versions that make it into package archives, there may be no solution for this at the moment. All the best, --"this user" > > Alan > __________________________ > Alan W. Irwin > > Astronomical research affiliation with Department of Physics and Astronomy, > University of Victoria (astrowww.phys.uvic.ca). > > Programming affiliations with the FreeEOS equation-of-state implementation > for stellar interiors (freeeos.sf.net); PLplot scientific plotting software > package (plplot.org); the libLASi project (unifont.org/lasi); the Loads of > Linux Links project (loll.sf.net); and the Linux Brochure Project > (lbproject.sf.net). > __________________________ > > Linux-powered Science > __________________________ > > ------------------------------------------------------------------------------ > Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day > trial. Simplify your report design, integration and deployment - and focus on > what you do best, core application coding. Discover what's new with > Crystal Reports now. http://p.sf.net/sfu/bobj-july > _______________________________________________ > Plplot-general mailing list > Plp...@li... > https://lists.sourceforge.net/lists/listinfo/plplot-general > -- David A. Ventimiglia <ven...@ms...> Michigan State University |
From: Arjen M. <arj...@de...> - 2009-11-18 07:48:54
|
Hello David, if I understand it correctly, you are using the packages provided by Ubuntu? As it happens, Tcl 8.5.8 was released yesterday (which includes the patch for xhost/send). You might want to try this: - Get ActiveState's Tcl 8.5.8 distribution - Build PLplot from the source distribution This ought to guarantee that you can use the correct version of Tcl within the context of PLplot. Of course this is more work than using the Ubuntu archives, but it seems a solution. Regards, Arjen > > Hello, it's "this user". :) I tried what you suggested, which is to > purge/reinstall Tcl/Tk, and here's what I found. > > With just the Canonical ppa archives enabled (i.e., the standard ones > when you install or upgrade to Karmic Koala), the PLplot available is > 5.9.2-3, and it seems the plplot-tcl package is configured with > dependencies on Tcl 8.4 and Tk 8.4, and not on Tcl/Tk 8.5. Whether I > have Tcl/Tk 8.5 installed or not, if I uninstall Tcl/Tk 8.4, then > plplot-tcl automatically uninstalls. And, if I reinstall plplot-tcl, > Tcl/Tk 8.4 automatically reinstalls. > > So, if the latest versions of Tcl/Tk are 8.5, and if they've been > patched in some way to allow the above xhost+ combination, but if Tcl/Tk > 8.4 do not allow this combination, then it looks like the current > packaging of plplot-tcl in the Canonical archives are just not current > enough because it's still using Tcl/Tk 8.4. > > At least...I think. Or maybe not. :) > > So, modulo the understandable lag between the most recent version of > software projects, and the versions that make it into package archives, > there may be no solution for this at the moment. > > All the best, > --"this user" > |
From: Arjen M. <arj...@de...> - 2009-11-17 14:24:15
|
Hi Andrew, this problem was recently fixed: see the bug report at https://sourceforge.net/tracker/index.php?func=detail&aid=1909931&group_id=12997&atid=112997 It seems to require some cooperation from the X server as well. Regards, Arjen On 2009-11-17 10:36, Andrew Ross wrote: > On Tue, Nov 17, 2009 at 08:54:09AM +0100, Arjen Markus wrote: >> >> On 2009-11-17 05:51, Alan W. Irwin wrote: >>> On 2009-11-16 20:29-0500 David A. Ventimiglia wrote: >>> >>>> Hi Alan, >>>> >>>> Thanks for the reply. I'm sorry, but I don't really understand X >>>> Windows security or the lack thereof, so I'll have to spend some time >>>> grokking this xhost business. :) In any event, it sounds like what >>>> you're saying is that this error is not a problem with Tcl, Tk, or >>>> PLplot, but rather a legitimate security hole that is either uncommon or >>>> doesn't exist at all on other Linux distros, but evidently does exist in >>>> Ubuntu Karmic Koala (at least, it does on my machine...I wonder what >>>> would happen if I'd done a clean install instead of an upgrade from >>>> Jaunty Jaguar). Is that correct? In that case, I suppose my queries >>>> should be redirected at the Ubuntu maintainers. :) >>> Yes, and yes. :-) >>> >> I can add some further information on the issue (from the man page of >> the Tcl/Tk send command): >> >> The send command is potentially a serious security loophole. On Unix, >> any application that can connect to your X server can send scripts to >> your applications. These incoming scripts can use Tcl to read and write >> your files and invoke subprocesses under your name. Host-based access >> control such as that provided by xhost is particularly insecure, since >> it allows anyone with an account on particular hosts to connect to your >> server, and if disabled it allows anyone anywhere to connect to your >> server. In order to provide at least a small amount of security, Tk >> checks the access control being used by the server and rejects incoming >> sends unless (a) xhost-style access control is enabled (i.e. only >> certain hosts can establish connections) and (b) the list of enabled >> hosts is empty. This means that applications cannot connect to your >> server unless they use some other form of authorization such as that >> provide by xauth. Under Windows, send is currently disabled. Most of the >> functionality is provided by the dde command instead. >> >> IIRC, Tcl/Tk can be compiled with a flag that turns off this security >> check, but I do not think that is a wise thing to do. > > Just to comment further, this issue has been around with Ubuntu (maybe also > Debian?) for a while. It is not a security issue. The default ubuntu setup > has xhost +SI:localuser:<username>, where username is the user logged on. > This allows the local user to display on the server - in particular it means > that x programs started via sudo will correctly display. You can disable > this, but then things like the package manager which need to run as root > won't work. I don't think this particular use of xhost is a security issue, > but tk is not that discriminating. The best course is probably to file a > bug against the tk package in Ubuntu. By default you would expect it to > work... The best solution would be a patch to tcl / tk to allow the localuser > case. > > Regards > > Andrew > > > ------------------------------------------------------------------------------ > Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day > trial. Simplify your report design, integration and deployment - and focus on > what you do best, core application coding. Discover what's new with > Crystal Reports now. http://p.sf.net/sfu/bobj-july > _______________________________________________ > Plplot-general mailing list > Plp...@li... > https://lists.sourceforge.net/lists/listinfo/plplot-general > |
From: Andrew R. <and...@us...> - 2009-11-17 15:03:05
|
Hi Arjen, That's good to know, if a little late for the current distributions. Ubuntu have just had a release. Andrew On Tue, Nov 17, 2009 at 03:23:59PM +0100, Arjen Markus wrote: > Hi Andrew, > > this problem was recently fixed: > see the bug report at > https://sourceforge.net/tracker/index.php?func=detail&aid=1909931&group_id=12997&atid=112997 > > It seems to require some cooperation from the X server as well. > > Regards, > > Arjen > > On 2009-11-17 10:36, Andrew Ross wrote: > > On Tue, Nov 17, 2009 at 08:54:09AM +0100, Arjen Markus wrote: > >> > >> On 2009-11-17 05:51, Alan W. Irwin wrote: > >>> On 2009-11-16 20:29-0500 David A. Ventimiglia wrote: > >>> > >>>> Hi Alan, > >>>> > >>>> Thanks for the reply. I'm sorry, but I don't really understand X > >>>> Windows security or the lack thereof, so I'll have to spend some time > >>>> grokking this xhost business. :) In any event, it sounds like what > >>>> you're saying is that this error is not a problem with Tcl, Tk, or > >>>> PLplot, but rather a legitimate security hole that is either uncommon or > >>>> doesn't exist at all on other Linux distros, but evidently does exist in > >>>> Ubuntu Karmic Koala (at least, it does on my machine...I wonder what > >>>> would happen if I'd done a clean install instead of an upgrade from > >>>> Jaunty Jaguar). Is that correct? In that case, I suppose my queries > >>>> should be redirected at the Ubuntu maintainers. :) > >>> Yes, and yes. :-) > >>> > >> I can add some further information on the issue (from the man page of > >> the Tcl/Tk send command): > >> > >> The send command is potentially a serious security loophole. On Unix, > >> any application that can connect to your X server can send scripts to > >> your applications. These incoming scripts can use Tcl to read and write > >> your files and invoke subprocesses under your name. Host-based access > >> control such as that provided by xhost is particularly insecure, since > >> it allows anyone with an account on particular hosts to connect to your > >> server, and if disabled it allows anyone anywhere to connect to your > >> server. In order to provide at least a small amount of security, Tk > >> checks the access control being used by the server and rejects incoming > >> sends unless (a) xhost-style access control is enabled (i.e. only > >> certain hosts can establish connections) and (b) the list of enabled > >> hosts is empty. This means that applications cannot connect to your > >> server unless they use some other form of authorization such as that > >> provide by xauth. Under Windows, send is currently disabled. Most of the > >> functionality is provided by the dde command instead. > >> > >> IIRC, Tcl/Tk can be compiled with a flag that turns off this security > >> check, but I do not think that is a wise thing to do. > > > > Just to comment further, this issue has been around with Ubuntu (maybe also > > Debian?) for a while. It is not a security issue. The default ubuntu setup > > has xhost +SI:localuser:<username>, where username is the user logged on. > > This allows the local user to display on the server - in particular it means > > that x programs started via sudo will correctly display. You can disable > > this, but then things like the package manager which need to run as root > > won't work. I don't think this particular use of xhost is a security issue, > > but tk is not that discriminating. The best course is probably to file a > > bug against the tk package in Ubuntu. By default you would expect it to > > work... The best solution would be a patch to tcl / tk to allow the localuser > > case. > > > > Regards > > > > Andrew > > > > > > ------------------------------------------------------------------------------ > > Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day > > trial. Simplify your report design, integration and deployment - and focus on > > what you do best, core application coding. Discover what's new with > > Crystal Reports now. http://p.sf.net/sfu/bobj-july > > _______________________________________________ > > Plplot-general mailing list > > Plp...@li... > > https://lists.sourceforge.net/lists/listinfo/plplot-general > > > > ------------------------------------------------------------------------------ > Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day > trial. Simplify your report design, integration and deployment - and focus on > what you do best, core application coding. Discover what's new with > Crystal Reports now. http://p.sf.net/sfu/bobj-july > _______________________________________________ > Plplot-general mailing list > Plp...@li... > https://lists.sourceforge.net/lists/listinfo/plplot-general > |