Re: An Idea/RFP: x group /
Andreas Rottmann <firstname.lastname@example.org> writes:
AR> Wht about a package that contains the following commands (yet to be
AR> xuseradd <user> # Add's the user to the x group
AR> xuserdel <user> # Deletes the user from the x group
AR> The package would have an config file where it lists all users that
AR> are allowed to use x (there must be an user that x runs under, I think
AR> best called x ;-)). The x startup script would then call xhost
AR> +<user>@localhost for all of these users, and the above commands would
AR> use xhost (if X is running) to update the status immediatly.
Does user-based xhost authentication work? At all?
AR> Since xhost supports NIS, it would be good to accept "users" like this
AR> nis:user@domain and, for network use user@host (one could simply pass
AR> names that contain '@' without appending '@localhost').
My impression is that anything involving NIS is horribly insecure. Is
there any encryption/authentication in the X protocol? AFAIK, the
Kerberos-based authentication is horribly broken and won't work with
any version of Kerberos 5 released within the past 5 years. Nothing
else is secure at all over the network. (Hence, the popularity of X
tunnelling over ssh.)
BTW, why would you *want* to do this? You're basically creating a
class of local and/or remote users who can spy on/take over arbitrary
users' X sessions. I'd be pretty scared if I was using a system and
another user's X windows started popping up on top of mine.
Other things to think about if you're really set on doing this: what
keeps the logged-in user from running 'xhost -user@localhost'? What
keeps someone on the acl from running 'xhost -:0.0'? What if there
are multiple X servers running on the machine?
David Maze email@example.com http://www.mit.edu/~dmaze/
"Theoretical politics is interesting. Politicking should be illegal."
-- Abra Mitchell
To UNSUBSCRIBE, email to firstname.lastname@example.org
with a subject of "unsubscribe". Trouble? Contact email@example.com