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
