x2go-dev

x2go-dev@lists.x2go.org

5397 discussions

Re: [X2go-dev] concept for X2go session lock-down to kiosk-mode (was Re: X2go is insecure)
by Dick Kniep 01 Apr '11

01 Apr '11

Hi list, Reading all comments on my stone in the pond I still think it is not really clear what the problem is (and my proposed solution) I do not want to secure the entire server. I only want a door that can be locked. So I allow a user to use the terminal. Okay he is allowed to use the terminal and so he can do anything he likes. No problem. Or I say on the server the user may only use program XYZ. XYZ starts and that is all. If XYZ deletes my system that is Okay by me. The user had access to that program and that is it. This can be enforced by my simple solution. From the client a command is sent, say "Start terminal". Then in the wrapper, the user is matched with the command and if the match exists, the command is allowed and is executed. If not, the request is rejected. Maybe this can be achieved also by apparmor, but it looks to me that apparmor is intended to secure the entire system which is really not what I want. (Or maybe I am mistaken because of lack of knowledge of apparmor) Dick Kniep -----Oorspronkelijk bericht----- Van: Mike Gabriel <mike.gabriel(a)das-netzwerkteam.de> Verzonden: wo 30-03-11 20:22:45 Aan: x2go-dev(a)lists.berlios.de; Dick Kniep <dick.kniep(a)lindix.nl>; Onderwerp: Re: [X2go-dev] concept for X2go session lock-down to kiosk-mode (was Re: X2go is insecure) Hi Dick, On Mi 30 Mär 2011 18:46:49 CEST Dick Kniep wrote: > We have developed the wrapper that does exactly what I describe > here. Currently it is lacking a screen where an authorized user can > change the authorization db, but that will come on short notice. > > I hope it is a little clearer now what the problem is and how it can > be solved. What I have been thinking the last day is that it might be much more generic and by far more effective to use the apparmor tool for this kind of lock-down. However, I have never played with apparmor, only in cases when the rules package maintainers had included in their packages were too strict... 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(a)das-netzwerkteam.de, http://das-netzwerkteam.de freeBusy: https://mail.das-netzwerkteam.de/freebusy/m.gabriel%40das-netzwerkteam.de.x…

6 6

Re: [X2go-dev] concept for X2go session lock-down to kiosk-mode (was Re: X2go is insecure)
by Dick Kniep 01 Apr '11

01 Apr '11

Hi LIst, I completely agree with you John, it looks like some people understand the need for this and others simply don't see the point (and probably for good reasons). However the problem is more complex than it seems, because to be able to use a wrapper, changes must be implemented in the clients. This is because the client cannot simply say anymore: x2gomount ... ... ... or any other command it needs to execute on the server, but it has to start this command thru the wrapper. So not only do we have to change the client, but also without extra measures we will be incompatible with earlier clients and most definitely older clients will not work with a newer server. That is, IF we implement this as a standard part of the X2go package. We could implement this by adding a package (x2gokiosk?) that alters the ssh config and adds the wrapper. Requirements for this solution are: An api is needed for communications between the server and the client that defines: - Kind of server that is there (x2goserver or x2gokiosk) - Version of the interface - Possibility to retrieve the allowed commands from the server In that case we get the best of both worlds. If one wants the extra security the x2gokiosk package offers, x2gokiosk is installed and there is no problem that older clients cannot connect anymore, because the user has chosen for the extra security. However if a newer client connects to an older server without the x2gokiosk package it should be able to see that there is no secure x2gokiosk on the other side and it should use the old way of connecting. In that case, also an older client with a newer server (no x2gokiosk) will work as expected. Cheers, Dick Kniep -----Oorspronkelijk bericht----- Van: John A. Sullivan III <jsullivan(a)opensourcedevel.com> Verzonden: vr 01-04-11 02:56:09 Aan: x2go-dev(a)lists.berlios.de; Onderwerp: Re: [X2go-dev] concept for X2go session lock-down to kiosk-mode (was Re: X2go is insecure) On Fri, 2011-04-01 at 02:44 +0200, Dick Kniep wrote: > Hi list, > > > > Reading all comments on my stone in the pond I still think it is not > really clear what the problem is (and my proposed solution) > > > I do not want to secure the entire server. I only want a door that can > be locked. So I allow a user to use the terminal. Okay he is allowed > to use the terminal and so he can do anything he likes. No problem. > > > > Or I say on the server the user may only use program XYZ. XYZ starts > and that is all. If XYZ deletes my system that is Okay by me. The user > had access to that program and that is it. > > > > This can be enforced by my simple solution. From the client a command > is sent, say "Start terminal". Then in the wrapper, the user is > matched with the command and if the match exists, the command is > allowed and is executed. If not, the request is rejected. > > > > Maybe this can be achieved also by apparmor, but it looks to me that > apparmor is intended to secure the entire system which is really not > what I want. (Or maybe I am mistaken because of lack of knowledge of > apparmor) <snip> Again I confess that I've not taken a lot of time to digest this issue but, I wonder if the back and forth is cause because for some users, this would be a highly desirable feature whereas, for others, it not only makes no sense but would be a significant obstacle. Can it be built as a configurable option that can be enabled with a setting in x2go.conf (or whatever file we are using for configuration)? - John _______________________________________________ X2go-dev mailing list X2go-dev(a)lists.berlios.de https://lists.berlios.de/mailman/listinfo/x2go-dev !DSPAM:4d9522a930777730779061!

1 0

Re: [X2go-dev] concept for X2go session lock-down to kiosk-mode (was Re: X2go is insecure)
by Dick Kniep 30 Mar '11

30 Mar '11

Hi list, First of all sorry for the somewhat provocative way I entered this discussion. Now about the use case we have: We are providing an application over the internet to users. This application should run seamlessly on the desktop of the user. So we do NOT export a complete desktop but only a single application. The users should be able to start this application, but nothing else...... Our users are on the Internet at random places. Some might logon with the nice python client of Mike, some might use an X2go plugin in a browser etc. As the users should only be able to execute our application and nothing more, security should be done at the server and NOT at the client. The way X2go works is that commands defined in the client are sent to the server and executed there. So if a user starts a desktop, the client sends the command to start the desktop to the server and it is executed there. The screen shows throught nx and he can work. From the moment the desktop is running, only the screens, the mouseclicks and keyboard is sent thru the tunnel. Because the user can change the profiles stored in the X2goclient, he could enter any command there and send it to the server. So, what I suggest is that on the server there is a file where the allowed user commands are stored per usergroup (Off-course Unix usergroups can be used here). This is not very complicated, because if the user is allowed to start the shell, this is only checked when the connection is made and not afterwards. This should be sufficient. Example ---------//----------- The group x2gousers on the server is allowed to execute the terminal and kde and a special application (say CVix, our application). So, when the user connects to the server, the server reports to the user, OK, you can start kde, the terminal or CVix. If the user chooses the terminal, then the terminal is started and the user can execute any command allowed for him in the terminal. Now this is a trivial example, because the user is allowed to execute the terminal and can do anything he likes. However if the user is only allowed to execute CVix, there is no way whatsover for him to circumvent this authorization, because the wrapper simply prohibits any command that is not defined in the db. ----------//---------- In the X2go client, commands must be executed on the server to build the session. The number of commands that must be issued by the client is not very high and can be delivered preconfigured with the X2go server in the allowed commands db. We have developed the wrapper that does exactly what I describe here. Currently it is lacking a screen where an authorized user can change the authorization db, but that will come on short notice. I hope it is a little clearer now what the problem is and how it can be solved. Dick Kniep -----Oorspronkelijk bericht----- Van: John A. Sullivan III <jsullivan(a)opensourcedevel.com> Verzonden: wo 30-03-11 11:44:06 Aan: x2go-dev(a)lists.berlios.de; Onderwerp: Re: [X2go-dev] concept for X2go session lock-down to kiosk-mode (was Re: X2go is insecure) On Wed, 2011-03-30 at 10:58 +0200, Erik Auerswald wrote: > Hi, > > On Tue, Mar 29, 2011 at 06:31:07PM +0200, Mike Gabriel wrote: > > On Di 29 Mär 2011 16:55:50 CEST Alexander Wuerstlein wrote: > >> On 11-03-29 15:36, Dick Kniep <dick.kniep(a)lindix.nl> wrote: > > > >> An authorized user running commands over ssh is not a security problem > >> at all. It works as intended. ssh provides shells. > > > > As Reinhard has mentioned in another post: Dicks setup requires a > > complete lock-down-kiosk-mode-kind-of-thing. He wants a user to be able > > to run a small set of commands only (i.e. the rootless applications he > > wants to provide to his customers). From his perspective AFAIK a user > > logged in via SSH is a security issue. May it be so. > > > >>> The $SSH_ORIGINAL_COMMAND contains the original command that the > >>> client wants to execute on the server. This command is checked against > >>> the allowed commands for the user within the wrapper. > >> > >> From the invocation I infer, that the intended language for the > >> wrapper is shellskript. This is extremely dangerous if intended as a > >> security measure like you claim. Also please note that it is very hard > >> to write such wrappers in a secure way, such that stuff like e.g. > >> 'allowed_command foo bar ; evil_command' is not possible. > > > > This is a very worthy remark!!! I also think that it needs quite an > > effort to script such a wrapper (and have it accepted in X2go > > upstream!!!) > > An example for rsync via SSH can be found at: > http://troy.jdmz.net/rsync/index.html > > The validate-rsync script there can be used as a starting point. > > Regards, > Erik I admit I have not thought this issue through thoroughly as I'm under a brutal deadline right now but I would think the problem is that one can use X2Go for application publishing and not just complete desktops. Do we know in advance every possible application one might want to publish via X2Go? If we did (and I can't imagine we would), would we want to identify those via X2Go or some other mechanism built more for the task? My guess is, since we are an application publishing application, we should leave restriction of applications to the sysadmin using the tools already at their disposal. Again, that is only a half baked thought but I think it has some merit - John _______________________________________________ X2go-dev mailing list X2go-dev(a)lists.berlios.de https://lists.berlios.de/mailman/listinfo/x2go-dev !DSPAM:4d92fb66203787818312239!

2 1

X2go is insecure
by Dick Kniep 30 Mar '11

30 Mar '11

Hi list, In the past few month, Mike has developed a very nice python client for x2go that caters to our need as a Application service provider. However during that period, we have investigated the security of X2go and it proves that X2go is an insecure product if used in a hostile environment like the Internet. I know many of you are wondering: But we are using ssh, how can that be insecure? Well, as many of you know, one can connect to a server with ssh with a terminal and execute commands on that server, including commands like rm -Rf * or other commands. Even if the shell is disabled, it is still possible to execute any command on the server by using ssh user@server 'command' The problem is caused by the fact that the x2go server does not restrict the commands that can be entered thru ssh. This is bad, but what is worse, is that the X2go clients actually use this security hole to start any command it needs. To make it secure, ssh should be configured to allow only a single command. This wrapper-command effectively checks server side whether a requested command is allowed and started by the proper user. Only if both criteria are met, the command can be executed. So in the configuration of the x2gossh daemon, the following line is added: ForceCommand="x2gowrapper.sh $SSH_ORIGINAL_COMMAND" ssh-rsa The $SSH_ORIGINAL_COMMAND contains the original command that the client wants to execute on the server. This command is checked against the allowed commands for the user within the wrapper. Currently we are developing this wrapper that checks whether a command is allowed. When this is ready, we will make this available to the X2go project. However, acceptance of this solution will only happen if the principle problem is recognized. In pyhoca-gui a distinction can be made between an x2go system user and the end-user that is running the application. This is a good start, but does not solve the problem mentioned above. However if combined with the wrapper it is a real secure solution, as in the wrapper, the system user can only execute a number of x2go commands, while the end-user can only execute another set of commands. Furthermore, the client should be able to request the allowed commands for the end-user from the server and show them. If a user wants to change a profile, he/she should be allowed to choose only from the allowed commands. Also by this method it should be possible to generate the profiles automatically from the data from the server combined with some general parameters (like client-side printing and ways to connect). Therefore the following changes are requested: 1. A seperate instance of the ssh daemon for x2go. 2. A wrapper that is ALWAYS called when connecting to the server by the ssh configuration 3. Separate users for the x2go system calls and the end-user 4. A change to the x2go clients to accomodate this change 5.An api on the server to request the allowed commands 6. Automatic generation of the configuration on the cliënt side. Anyone willing to make a comment, please do so. The overall quality will only increase! Dick Kniep

8 8

Suggestion: Make x2gothinclientsystem less invasive
by Michael Hierweck 25 Mar '11

25 Mar '11

Hi x2go folks, I would like to suggest a solution to make x2gothinclientsystem less invasive. Instead of mounting a ramdisk and removing/symlinking some files and directories (which might be a Debian packaging policy violation) it might be smarter to mount a read only root filesystem and transparently overlay it with a tempfs. I can this be achieved? a) Install aufs modules in the clients' chroot environment. Aufs modules are part of Squeeze's default kernel. b) Add "aufs" to /etc/initramfs-tools/modules. c) Set "BOOT=aufs" in /etc/initramfs-tools/initramfs.conf. d) Add a "magic" script (see attachment) named "aufs" to /etc/initramfs-tools/scripts e) Call update-initramfs -u inside the chroot. The "aufs" script is based on Debian's /usr/share/initramfs-tools/scripts/nfs script. The attached script provides a three layer file root filesystem. ro nfsroot/master (generic thinclients' chroot) ro nfsroot/<ip-address> (individual thinclient's configuration overriding master) rw tempfs (simulates a fully rw root file system) Pros: * simple (to my mind) * flexible * less "hacky" (less/no conflicts with other packages) * therefore more Debian compliant (to my mind) * x2go related stuff currently stored in /ramdisk can go into /var/lib/x2go... Cons: * any? Any feedback is appreciated. Michael -- EDV-Serviceteam Annika & Michael Hierweck GbR Egerstraße 53, 44225 Dortmund (Germany) http://www.edv-serviceteam.net # NFS filesystem mounting -*- shell-script -*- # FIXME This needs error checking retry_nr=0 # parse nfs bootargs and mount nfs do_nfsmount() { configure_networking # get nfs root from dhcp if [ "x${NFSROOT}" = "xauto" ]; then # check if server ip is part of dhcp root-path if [ "${ROOTPATH#*:}" = "${ROOTPATH}" ]; then NFSROOT=${ROOTSERVER}:${ROOTPATH} else NFSROOT=${ROOTPATH} fi # nfsroot=[<server-ip>:]<root-dir>[,<nfs-options>] elif [ -n "${NFSROOT}" ]; then # nfs options are an optional arg if [ "${NFSROOT#*,}" != "${NFSROOT}" ]; then NFSOPTS="-o ${NFSROOT#*,}" fi NFSROOT=${NFSROOT%%,*} if [ "${NFSROOT#*:}" = "$NFSROOT" ]; then NFSROOT=${ROOTSERVER}:${NFSROOT} fi fi if [ -z "${NFSOPTS}" ]; then NFSOPTS="-o retrans=10" fi [ "$quiet" != "y" ] && log_begin_msg "Running /scripts/nfs-premount" run_scripts /scripts/nfs-premount [ "$quiet" != "y" ] && log_end_msg if [ ${readonly} = y ]; then roflag="-o ro" else roflag="-o rw" fi mkdir -p /aufs-root mkdir -p /aufs-conf mkdir -p /aufs-temp nfsmount -o nolock ${roflag} ${NFSOPTS} ${NFSROOT}/master /aufs-root nfsmount -o nolock ${roflag} ${NFSOPTS} ${NFSROOT}/config/${IPV4ADDR} /aufs-conf mount -t tmpfs tmpfs /aufs-temp mount -t aufs -o dirs=/aufs-temp=rw:/aufs-conf=ro:/aufs-root=ro aufs ${rootmnt} } # NFS root mounting mountroot() { [ "$quiet" != "y" ] && log_begin_msg "Running /scripts/nfs-top" run_scripts /scripts/nfs-top [ "$quiet" != "y" ] && log_end_msg modprobe nfs # For DHCP modprobe af_packet wait_for_udev 10 # Default delay is around 180s # FIXME: add usplash_write info if [ -z "${ROOTDELAY}" ]; then delay=180 else delay=${ROOTDELAY} fi # loop until nfsmount succeds while [ ${retry_nr} -lt ${delay} ] && [ ! -e ${rootmnt}${init} ]; do [ ${retry_nr} -gt 0 ] && \ [ "$quiet" != "y" ] && log_begin_msg "Retrying nfs mount" do_nfsmount retry_nr=$(( ${retry_nr} + 1 )) [ ! -e ${rootmnt}${init} ] && /bin/sleep 1 [ ${retry_nr} -gt 0 ] && [ "$quiet" != "y" ] && log_end_msg done [ "$quiet" != "y" ] && log_begin_msg "Running /scripts/nfs-bottom" run_scripts /scripts/nfs-bottom [ "$quiet" != "y" ] && log_end_msg }

3 3

Re: [X2go-dev] [X2go-user] LDAP-Problem: Zertifikateproblem
by Mike Gabriel 23 Mar '11

23 Mar '11

Hi Mike, On Mi 23 Mär 2011 14:21:12 CET wrote: > Yes, I know that LDAP is not absolutely necessary. I am using x2go > already that way. This is to make a test installation for a > presentation of the software with the option of using it for a > company, so LDAP is an option. I would like to use it, but I am not > experienced with LDAP yet myself and the one who is experienced > proposes NX. > Plus one can only gain experiences. Do you want to use the load balancing support of X2go/LDAP? Or do you just want to administrate users in LDAP. For the latter, I personally recommend setting up your LDAP tree manually (there are plenty of howtos in the web for this...). For learning LDAP this should be your way to go. Then make sure you can use LDAP as libnss and pam source for passwd, group, shadow. At last you have to make sure that LDAP users are in the x2gousers group (which can be local or also a group in LDAP). Once you have that, LDAP users can login via X2go. [Once you have such a simple LDAP DIT up and running you might want to start from scratch and set up an LDAP-server that gets administered by GOsa² or CIPUX ;-) ...] If you want to use load balancing with X2go, then this should also be possible manually, but basically that's what the scripts were intended for (they were also intended for easy LDAP-setup, but you can do this manually...). However, to my personal view, the LDAP implementation needs quite some work before the Baikal release and also needs proper documentation of the way LDAP data is used and interpreted... Maybe someone else has experience on LDAP/loadbalancing... 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(a)das-netzwerkteam.de, http://das-netzwerkteam.de freeBusy: https://mail.das-netzwerkteam.de/freebusy/m.gabriel%40das-netzwerkteam.de.x…

1 1

Re: [X2go-dev] Bump LDAP / AD / Pulseaudio related login issues
by Robert Schumann 23 Mar '11

23 Mar '11

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 > Date: Wed, 23 Mar 2011 09:10:58 -0000 (GMT) > From: "--[ UxBoD ]--" <uxbod(a)splatnix.net> > Robert, > as John has mentioned we use LDAP with AD in our environment. The local/central database holds details pertinent to the session state eg. mounted shares; whereas the authentication is performed against whatever you have configured in PAM. Have you integrated Linux authentication with AD yet ? Phil, thanks for your answer. Yes I have already integrated AD into my Linux boxes. The user is authenticated through winbind. Everything works like expected, all the NX clients and plain SSH - for the login I have to use a scheme like DOMAIN\USER or USER@DOMAIN because we have a multi-trusted domain environment here. I cannot enable "use default domain" in Samba therefore. For plain SSH I can run it like that: ssh 'domain\user'@box and it's working. For x2go no matter if I use "\" or "@", they both seem to result in some trouble (not created folders and links on the box, or if they are created then the "\" is missing and the session ID refers to a non existing folder). Most stuff is called from the client, but when ending the session a perl script on the server fails too, because it cannot find the cmdoutput file IIRC. Cheers Robert - -- |-----------------------------------------------------address-+ | work: jacob-und-wilhelm-grimm-zentrum | geschwister-scholl-str. 1, 10117 berlin | postal: humboldt-universität zu berlin | computer- und medienservice | unter den linden 6 | 10099 berlin |-----------------------------------------------------contact-+ | mail: schumann(a)informatik.hu-berlin.de | icq: 93163687 | xmpp: betulichergutmensch(a)googlemail.com | huchat: schumanr(a)chat.hu-berlin.de | phone: +49(0)30-2093-70133 |-----------------------------------------------------gpg/pgp-+ | key: remembrance.de/gpg/0xA5A5FAA2.asc | fprint: 9220-9732-7390-7A0C-5623-3336-4233-FDF8-A5A5-FAA2 |-------------------------------------------------------------+ -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.11 (GNU/Linux) Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org/ iEYEARECAAYFAk2J1yMACgkQQjP9+KWl+qJVJwCeKnpWKu57zfhII8p5Ew/fRDtv NyMAn2NmEqzQPjQGvXU8n85smBJY3d3M =gmmM -----END PGP SIGNATURE-----

1 0

Bump LDAP / AD / Pulseaudio related login issues
by Robert Schumann 23 Mar '11

23 Mar '11

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Heyho guys, since nobody responded to my mail I sent on the 7th of February I'd like to bring that topic up again. While I'm totally agreeing with you that there are other important problems to solve, I consider the lack of a proper login in bigger networks a major showstopper for your project. It can only be of your interest, that people in a LDAP/AD configuration with usernames like DOMAIN\USER are able to use your services. I pointed out, that it's probably just a few fixes away from a solution. I'm understanding that your test case focusses on local users in some kind of databases, but however... I hardly see this as a "normal environment" in every company or organization which might want to use x2go. Really nobody is using local user databases on some Linux machine for storing user information and accounts except for Bob and Alice maybe. If any of you likes to investigate this issue I can provide an writable x2go server and a domain account to test things out and find fixes for that. Best regards Robert - -- |-----------------------------------------------------address-+ | work: jacob-und-wilhelm-grimm-zentrum | geschwister-scholl-str. 1, 10117 berlin | postal: humboldt-universität zu berlin | computer- und medienservice | unter den linden 6 | 10099 berlin |-----------------------------------------------------contact-+ | mail: schumann(a)informatik.hu-berlin.de | icq: 93163687 | xmpp: betulichergutmensch(a)googlemail.com | huchat: schumanr(a)chat.hu-berlin.de | phone: +49(0)30-2093-70133 |-----------------------------------------------------gpg/pgp-+ | key: remembrance.de/gpg/0xA5A5FAA2.asc | fprint: 9220-9732-7390-7A0C-5623-3336-4233-FDF8-A5A5-FAA2 |-------------------------------------------------------------+ -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.11 (GNU/Linux) Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org/ iEYEARECAAYFAk2IjrgACgkQQjP9+KWl+qKvMACcDksNkkhnLmrN5HmjAlcAUE4i GW4An1kDm46a3QIkhYPAZ62sfr+NGjqm =7DSP -----END PGP SIGNATURE-----

4 3

Trinity and X2go
by Mike Gabriel 22 Mar '11

22 Mar '11

Hi x2go-dev, I have just started upgrading my always-as-stable-as-possible-Debian-office-computer to Debian squeeze and installed Trinity (KDE3.5 fork). Not that my personal todo list and probably those of others are not long enough already, but we should definitely add Trinity support to X2go. @John: in one of your postings lately I may remember you mentioning Trinity in relation to X2go. Do you have any patches or a howto for an installation. Basically, I think an adaptation of x2gokdebindings and the x2gostartagent script shouldn't be too difficult... 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(a)das-netzwerkteam.de, http://das-netzwerkteam.de freeBusy: https://mail.das-netzwerkteam.de/freebusy/m.gabriel%40das-netzwerkteam.de.x…

2 3

Wishlist: x2gofeatures query before session start
by Mike Gabriel 22 Mar '11

22 Mar '11

Hi there, Here is a feature request proposal for the post-Baikal release (Rebun): The handshake on session start should be extended in the following way: o login as user o call a script x2gofeatures (or similar) o this script replies with some file format that states - user may / must not start an X2go session - user may / must not start in rootless/desktop mode - available commands to execute (KDE, TERMINAL, /usr/bin/xterm...) - user may / must not print - user may / must not use audio - ... o the client should obey to this returned list of features o if the user tries to hack some feature that he/she is not allowed to use, the server of course also has to deny this feature (and maybe even the whole session) 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(a)das-netzwerkteam.de, http://das-netzwerkteam.de freeBusy: https://mail.das-netzwerkteam.de/freebusy/m.gabriel%40das-netzwerkteam.de.x…

5 13

Jump to page:

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

x2go-dev