On 2011-03-21 09:44, Mike Gabriel wrote:
I share your opinion. So there are two parts of such a feature...
- control management through the available posix etc. mechanisms
- 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
On Mon, 2011-03-21 at 10:31 +0100, Moritz Struebe wrote: 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>