[X2go-dev] Wishlist: x2gofeatures query before session start

[Mike Gabriel]

Hi Morty,

On Mo 21 Mär 2011 10:31:58 CET 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.

This was discussed before on this list and there are use cases that  
demand SSH access, but no x2go startup permission. So we should try to  
be compliant to these wishes within the community, I think.

> For most of the stuff ACLs seem
> the way to go.

You mean filesystem ACLs here? The normal user, group, others triple  
or the extACL feature? I am still not clear about this.

> 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.....

I guess you cannot really forbid audio, you could only try to make it  
as hard as possible to get sound from the server (refuse copying the  
pulse-cookie, not setting the PULSE_CLIENTCONFIG variable etc.).

A use case for no-audio could for performance reasons...

> I also don't see why this should speed things up. If someone connects
> according to the "rules" there should be no delay and if he doesn't -
> we'll then only the one who is trying to use those features is to blame....

Ok, I partially agree on this... However, an x2gofeatures call could  
help the client to sort out proper errors/warnings that could be send  
to the user as GUI message boxes etc. So this would not be for  
security, but for an enhancement of usability...

> If again you want a preconfigured client which give the user a certain
> number of preconfigured options (e.g. start App1, App4 or App8) this is
> something completely different. But this is a matter of usability not
> security..... (Or security by convenience.... )

For PyHoca-GUI I plan something I will call embedded menus. The menus  
will be generated on the server and shown with the menu structure of  
PyHoca-GUI. For this I need to be able to query the server about  
applications to offer to the user. This will not be for security (with  
an xterm the user could startup any command available on the server),  
but for usability.

Greets,
Mike


-- 

DAS-NETZWERKTEAM
mike gabriel, dorfstr. 27, 24245 barmissen
fon: +49 (4302) 281418, fax: +49 (4302) 281419

GnuPG Key ID 0xB588399B
mail: mike.gabriel at das-netzwerkteam.de, http://das-netzwerkteam.de

freeBusy:
https://mail.das-netzwerkteam.de/freebusy/m.gabriel%40das-netzwerkteam.de.xfb
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 489 bytes
Desc: Digitale PGP-Unterschrift
URL: <http://lists.x2go.org/pipermail/x2go-dev/attachments/20110321/1da5987d/attachment.pgp>