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
