On Thu, 2005-10-06 at 14:24 +0200, Christof Douma wrote: > On Thu, Oct 06, 2005 at 10:06:50AM +1000, Drew Parsons wrote: > > Not useless, only if there's a local user vindictive enough to cause > > this sort of disruption. > I have in mind the usual setup on a univerity, school or workplace. It > is common to have some malicious users between them. I did not found > usernames in the log, so a system administrator has no way to find the > user who 'broke' Xprt. >
Yes, I agree in general it's a real problem. > > I'm not sure how enthusiastic some systems would be to have an Xprt > > instance running for every single user, however. It's not what it's > > generally intended for. > Xprt and X can be started at anytime by a user and they can continue > running after the user leaves. This is a problem the system > adminstrators have already. I don't think it is strange to make Xprt > synchronize with X startup, faking the one server setup we will probably > get someday in the future. But I admit that it would be better to run a > single deamon. Hmm, are you aware that Xprt *can* already be started by a normal user. I'm not aware of any serious difficulties doing this. They can't use /etc/init.d/xprint to do it easily, but Xprt will lauch from the command line (copy from "ps aux | grep [X][rt", use a different display number). The /etc/init.d/xprint automates identification of the font paths and tracks the current running instance of Xprt. It could be adapted so that, per user, it still does the former while skipping over the latter. It could be put into ~/.xsession or wherever. I think you could turn this into a solution easily enough, or at least a workaround. I might even dare to close this bug on that basis :) > > I saw in the man page of Xsecurity that there are a lot of different > authetication methods in Xprt. It looks like MIT-MAGIC-COOKIE-1 is > usefull: > > It is running in no-listen mode anyway. When a user has a cookie he > cannot be excluded by other users. Giving the cookie can be done > together with setting the environment or something like that. > > Please note that I have no experience with security of X servers, so I > might be way of... :-D Yes, may also be helpful. I'm no X-security expert either! Drew -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
