On Mon, 2011-03-21 at 10:31 +0100, Moritz Struebe wrote: > On 2011-03-21 09:44, Mike Gabriel wrote: > > I share your opinion. So there are two parts of such a feature... > > > > 1. control management through the available posix etc. mechanisms > > 2. a script x2gofeatures, that can tell the client what is allowed > > and what > > not: if the server can tell the client what's possible and what > > not the > > session start up will be much faster compared to stumbling over a > > couple > > of session errors during session handshakes > > > > Would apparmor be one way to go? Do you already have a clearer idea > > how you would tighten up a system? > > I personally don't see a reason why I shouldn't give some ssh-access and > disallow him to run x2go / sound, etc. For most of the stuff ACLs seem > the way to go. For sound I have no idea how you want to keep someone > from connecting to a server of his choosing - unless you jump through > some hoops. Again I don't see why you want to keep someone from using > sound anyway..... Performance in a WAN environment comes immediately to mind. One may also have restrictions about noise in the work place but, if that were the case, one would probably disable the sound devices on the physical computer - then again, some other user may have a use case where it legitimately makes sense to conform to noise restrictions by configuring the X2Go server - John <snip>
_______________________________________________ X2go-dev mailing list X2go-dev@lists.berlios.de https://lists.berlios.de/mailman/listinfo/x2go-dev
