[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: An Idea/RFP: x group /

Andreas Rottmann <a.rottmann@gmx.at> writes:
AR> Wht about a package that contains the following commands (yet to be
AR> written):
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             dmaze@mit.edu          http://www.mit.edu/~dmaze/
"Theoretical politics is interesting.  Politicking should be illegal."
	-- Abra Mitchell

To UNSUBSCRIBE, email to debian-devel-request@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org

Reply to: