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
