Re: [SLUG] X authorization
jam wrote: This POS is not in operation I'd come at this another way, and use a login theme or screensaver to display the not in use text. Mainly because if the terminal is saying it is not in use then it shouldn't be usable. Whereas if you just paste up a some text using X then the keyboard will still work, which might be confusing when someone cleans the keyboard. Anyway, your problem is almost certainly that X isn't running TCP. That's controlled by the GDM settings. Don't forget to modify the firewall too. -- Glen Turner -- SLUG - Sydney Linux User's Group Mailing List - http://slug.org.au/ Subscription info and FAQs: http://slug.org.au/faq/mailinglists.html
Re: [SLUG] X authorization
On 06/09/2008, at 12:49 PM, jam wrote: On Saturday 06 September 2008 09:44:12 [EMAIL PROTECTED] wrote: I need to understand X authorization so if anybody can explain to a bear of little brain :-) Once-upon-a-time xhost + would allow anybody to write to your display. That is no longer true What makes you think that? There have been some changes to X security over the years, but the fundamental mechanisms are still in place... saturn is a CentOS 5 machine: [eeyore] /home/jam [53]% ssh -X saturn xhost + access control disabled, clients can connect from any host [eeyore] /home/jam [54]% export DISPLAY=saturn:0 xmessage hello world Error: Can't open display: saturn:0 argh. WRONG WRONG WRONG. xhost also uses X protocol to modify the access control, so all your first command did was disable access control in your client's X server (on eeyore?, not on saturn). The reason why xhost + doesn't seem to work on a lot of linux systems is that TCP sessions are disabled by default in most deployments (forcing you to use unix domain sockets), forcing you to use a X11 protocol forwarder (such as ssh) to get to the Xserver. If security is not a concern, start the X server on saturn with -ac so access control is disabled completely in that server rather than trying to xhost it. C. -- SLUG - Sydney Linux User's Group Mailing List - http://slug.org.au/ Subscription info and FAQs: http://slug.org.au/faq/mailinglists.html
Re: [SLUG] X authorization
On Monday 08 September 2008 07:59:29 [EMAIL PROTECTED] wrote: I need to understand X authorization so if anybody can explain to a bear of little brain :-) Once-upon-a-time xhost + would allow anybody to write to your display. That is no longer true What makes you think that? There have been some changes to X security over the years, but the fundamental mechanisms are still in place... saturn is a CentOS 5 machine: [eeyore] /home/jam [53]% ssh -X saturn xhost + access control disabled, clients can connect from any host [eeyore] /home/jam [54]% export DISPLAY=saturn:0 xmessage hello world Error: Can't open display: saturn:0 argh. WRONG WRONG WRONG. xhost also uses X protocol to modify the access control, so all your first command did was disable access control in your client's X server (on eeyore?, not on saturn). Sorry, tried to be too clever and confused things. For this EG I am on eeyore and want to display a message on saturn, so indeed this is correct ssh -X saturn xhost + The reason why xhost + doesn't seem to work on a lot of linux systems is that TCP sessions are disabled by default in most deployments (forcing you to use unix domain sockets), forcing you to use a X11 protocol forwarder (such as ssh) to get to the Xserver. As many have pointed out TCP is the issue. Why is port 6000 closed with no tcp ? (clearly security, is it just to disable the xhost suit of ways) How would you use ssh to run a program on eeyore, from eeyore, but display on saturn? The opposite is trivial ie display HERE a program running THERE. If security is not a concern, start the X server on saturn with -ac so access control is disabled completely in that server rather than trying to xhost it. This thin clients DO (-ac) and it does not work, which is how this thread started :-) (but almost certainly the thin clients do no-tcp) Thanks James -- SLUG - Sydney Linux User's Group Mailing List - http://slug.org.au/ Subscription info and FAQs: http://slug.org.au/faq/mailinglists.html
[SLUG] X authorization
I need to understand X authorization so if anybody can explain to a bear of little brain :-) Once-upon-a-time xhost + would allow anybody to write to your display. That is no longer true I have some thin clients (ltsp) running off a server. I actually *really* need to write to the display (as opposed to sending a message ie jabber to to user) eg This POS is not in operation I cannot see how xauth would help: The POS daemon program disables terminal say, um 17 and puts a message on terminal 17 Disabled etc but neither it (The POS daemon) or the user associated with it are running a display and may not even be the same server as the LTSP server. So my basic problem: I need to put a message (say with xmessage) on a ThinClient DISPLAY whether-or-not that terminal is logged in, and I can't understand the relevant man pages / howtos. I tried asking the ltsp forums and got nervous evasion. Anybody here know? Thanks James -- SLUG - Sydney Linux User's Group Mailing List - http://slug.org.au/ Subscription info and FAQs: http://slug.org.au/faq/mailinglists.html
Re: [SLUG] X authorization
jam [EMAIL PROTECTED] writes: I need to understand X authorization so if anybody can explain to a bear of little brain :-) Once-upon-a-time xhost + would allow anybody to write to your display. That is no longer true What makes you think that? There have been some changes to X security over the years, but the fundamental mechanisms are still in place... So, presumably you have tested this and found that it doesn't work. How did you test, and what was the error you encountered? I have some thin clients (ltsp) running off a server. I actually *really* need to write to the display (as opposed to sending a message ie jabber to to user) eg Are you absolutely, positively sure that you want to allow anyone to connect to the display? This is a security nightmare, as anyone allowed to connect can also capture and forge *all* keyboard and mouse input. This POS is not in operation I cannot see how xauth would help: The POS daemon program disables terminal say, um 17 and puts a message on terminal 17 Disabled etc but neither it (The POS daemon) or the user associated with it are running a display and may not even be the same server as the LTSP server. xauth is responsible for managing the (marginally) more secure authentication mechanisms for X connections -- you don't actually /need/ a display to use it effectively on an X client. For example, ssh X forwarding uses xauth to allow X software to run on a remote machine and display relatively securely on the local client. Now, you do have a problem: So my basic problem: I need to put a message (say with xmessage) on a ThinClient DISPLAY whether-or-not that terminal is logged in, and I can't understand the relevant man pages / howtos. Getting access while a session is logged in isn't that dire: you need to arrange for your message source to have access to an X connection to the appropriate LTSP machine. That means either host-based trust (xhost +message-source.local) or a more secure authentication mechanism (xauth with an appropriate key.) You might want to generate the appropriate MIT-MAGIC-COOKIE-1 data and arrange for your message source to have access to it, if security is a concern. While the login session is active, though, you have a bigger problem: you will need to do work on your login manager to achieve the same results. For the standard xdm, gdm or kdm system this isn't too dire -- all of them run scripts, as root, to perform session setup before displaying the chooser or login panel, and you should be able to use that to achieve the same result. For a more custom display manager, which I understand LTSP to use, you will need to do something more clever. I tried asking the ltsp forums and got nervous evasion. Anybody here know? I can't say I am surprised, since this is actually reasonably challenging in many ways; the security architecture, and the trade-offs in security make this a difficult approach. Perhaps you might find another approach effective: can you have the POS software manage authentication, and be able to display the not in use banner? That would make one bit of software responsible for all of this, which would make it a lot easier to manage. Alternately, can you SSH to the machine as the logged in user (or root), then run the message software locally? Regards, Daniel -- SLUG - Sydney Linux User's Group Mailing List - http://slug.org.au/ Subscription info and FAQs: http://slug.org.au/faq/mailinglists.html
Re: [SLUG] X authorization
On Saturday 06 September 2008 09:44:12 [EMAIL PROTECTED] wrote: I need to understand X authorization so if anybody can explain to a bear of little brain :-) Once-upon-a-time xhost + would allow anybody to write to your display. That is no longer true What makes you think that? There have been some changes to X security over the years, but the fundamental mechanisms are still in place... saturn is a CentOS 5 machine: [eeyore] /home/jam [53]% ssh -X saturn xhost + access control disabled, clients can connect from any host [eeyore] /home/jam [54]% export DISPLAY=saturn:0 xmessage hello world Error: Can't open display: saturn:0 So, presumably you have tested this and found that it doesn't work. How did you test, and what was the error you encountered? All the stuff that DOES work on a RedHat 9 system tried and does NOT work here I have some thin clients (ltsp) running off a server. I actually *really* need to write to the display (as opposed to sending a message ie jabber to to user) eg Are you absolutely, positively sure that you want to allow anyone to connect to the display? This is a security nightmare, as anyone allowed to connect can also capture and forge *all* keyboard and mouse input. This in a typical hungry jacks store: private lan and *nothing* but the POS and manager machines present. I'm not adverse to being more clever, I just inherited a real not-nice setup and am trying to clean up the mess. This POS is not in operation I cannot see how xauth would help: The POS daemon program disables terminal say, um 17 and puts a message on terminal 17 Disabled etc but neither it (The POS daemon) or the user associated with it are running a display and may not even be the same server as the LTSP server. xauth is responsible for managing the (marginally) more secure authentication mechanisms for X connections -- you don't actually /need/ a display to use it effectively on an X client. More RTBM (the bloody manual) :-) I understood using xauth to get the .Xauthority from one machine and import to another For example, ssh X forwarding uses xauth to allow X software to run on a remote machine and display relatively securely on the local client. Now, you do have a problem: So my basic problem: I need to put a message (say with xmessage) on a ThinClient DISPLAY whether-or-not that terminal is logged in, and I can't understand the relevant man pages / howtos. Getting access while a session is logged in isn't that dire: you need to arrange for your message source to have access to an X connection to the appropriate LTSP machine. That means either host-based trust (xhost +message-source.local) or a more secure authentication mechanism (xauth with an appropriate key.) You might want to generate the appropriate MIT-MAGIC-COOKIE-1 data and arrange for your message source to have access to it, if security is a concern. While the login session is active, though, you have a bigger problem: you will need to do work on your login manager to achieve the same results. For the standard xdm, gdm or kdm system this isn't too dire -- all of them run scripts, as root, to perform session setup before displaying the chooser or login panel, and you should be able to use that to achieve the same result. For a more custom display manager, which I understand LTSP to use, you will need to do something more clever. I tried asking the ltsp forums and got nervous evasion. Anybody here know? I can't say I am surprised, since this is actually reasonably challenging in many ways; the security architecture, and the trade-offs in security make this a difficult approach. Perhaps you might find another approach effective: can you have the POS software manage authentication, and be able to display the not in use banner? That would make one bit of software responsible for all of this, which would make it a lot easier to manage. Alternately, can you SSH to the machine as the logged in user (or root), then run the message software locally? Daniel that was most informative and helped me lots. Thank you. James -- SLUG - Sydney Linux User's Group Mailing List - http://slug.org.au/ Subscription info and FAQs: http://slug.org.au/faq/mailinglists.html
Re: [SLUG] X authorization
jam [EMAIL PROTECTED] writes: On Saturday 06 September 2008 09:44:12 [EMAIL PROTECTED] wrote: I need to understand X authorization so if anybody can explain to a bear of little brain :-) Once-upon-a-time xhost + would allow anybody to write to your display. That is no longer true What makes you think that? There have been some changes to X security over the years, but the fundamental mechanisms are still in place... saturn is a CentOS 5 machine: [eeyore] /home/jam [53]% ssh -X saturn xhost + access control disabled, clients can connect from any host [eeyore] /home/jam [54]% export DISPLAY=saturn:0 xmessage hello world Error: Can't open display: saturn:0 Are you sure that saturn is listening for X connections via TCP, and to connections from anything but localhost? Out of the box most modern systems configure X so that remote TCP isn't possible. (For example, my current X server does not listen for TCP at all.) [...] I have some thin clients (ltsp) running off a server. I actually *really* need to write to the display (as opposed to sending a message ie jabber to to user) eg Are you absolutely, positively sure that you want to allow anyone to connect to the display? This is a security nightmare, as anyone allowed to connect can also capture and forge *all* keyboard and mouse input. This in a typical hungry jacks store: private lan and *nothing* but the POS and manager machines present. I'm not adverse to being more clever, I just inherited a real not-nice setup and am trying to clean up the mess. No worries. I figure it is better to ask (redundantly) than to have you discover the problem later. :) This POS is not in operation I cannot see how xauth would help: The POS daemon program disables terminal say, um 17 and puts a message on terminal 17 Disabled etc but neither it (The POS daemon) or the user associated with it are running a display and may not even be the same server as the LTSP server. xauth is responsible for managing the (marginally) more secure authentication mechanisms for X connections -- you don't actually /need/ a display to use it effectively on an X client. More RTBM (the bloody manual) :-) I understood using xauth to get the .Xauthority from one machine and import to another There isn't that much more to it than that -- the X server has a list of xauth managed authorities that are allowed to connect, and xauth is a command line tool to move them around and make them available to the X client libraries. :) If you already know how to move them between machines you probably actually have half the battle solved, and will need very little time with the manual. (Also, I sympathise. The manual for X security related stuff is awful, which is a large part of why it took ten years for *any* significant use of the SECURITY extension to get out into the wider distributions, and then only thanks to OpenBSD via OpenSSH. Reading them and trying to work out how this works is not fun.) [...] Daniel that was most informative and helped me lots. Thank you. No worries. I hope you can resolve your issue. One final thought: if you trust the users then an option would be to run a second X server on an additional virtual terminal on each POS register. Have that do *nothing* but display your not in service banner, and disable server zap, etc, etc. No window manager, nothing useful, just the banner. You could then disable a POS terminal with: ssh [EMAIL PROTECTED] chvt 8 Substitute 8 for the VT where the second, not in service, banner software is running. From there the console can't do much to change away. Reversing the process is as simple as the same action, back to the live VT. That is, I think, the process I would use to manage this. It makes life a *lot* easier for everyone involved, because you no longer have to worry about security -- you just have your one, single, place to set in or out of service (active VT), and full control over the banner environment (so no worries about a session being active or not.) To further reduce (or, at least, change) complexity, you could also use a graphical Linux console and a framebuffer image view/display tool rather than a second X server. Regards, Daniel -- SLUG - Sydney Linux User's Group Mailing List - http://slug.org.au/ Subscription info and FAQs: http://slug.org.au/faq/mailinglists.html
[SLUG] X authorization error messages
Sluggers, I've just installed Debian on a VMware virtual machine, and I'm trying to get it to run X. So I installed the packages and the xdm login screen comes up no problems. When I try to log in however it appears to accept my username etc but then it just throws me back out. In the users .xsession-errors file there are messages like, Xlib: connection to ":0.0" refused by the server Xlib: Client is not authorized to connect to Server /usr/bin/X11/WindowMaker fatal error:could not open Display ":0" If I kill off X and xdm and log in as root on the console and then do a "startx", no problems. A normal user however cannot startx, it just flicks up then dies. Hints? Thanks Pete -- SLUG - Sydney Linux User Group Mailing List - http://slug.org.au/ More Info: http://slug.org.au/lists/listinfo/slug
