Andreas Rottmann <[EMAIL PROTECTED]> writes: AR> Wht about a package that contains the following commands (yet to be AR> written): AR> AR> xuseradd <user> # Add's the user to the x group AR> xuserdel <user> # Deletes the user from the x group AR> 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:[EMAIL PROTECTED] and, for network use [EMAIL PROTECTED] (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 [EMAIL PROTECTED]'? 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 PROTECTED] http://www.mit.edu/~dmaze/ "Theoretical politics is interesting. Politicking should be illegal." -- Abra Mitchell -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
