X2Go Bug report logs - #701
We need to talk about, and document, which options are overridable in which way

Full log

🔗 View this message in rfc822 format

X-Loop: owner@bugs.x2go.org
Subject: Bug#701: We need to talk about, and document, which options are overridable in which way
Reply-To: Stefan Baur <X2Go-ML-1@baur-itcs.de>, 701@bugs.x2go.org
Resent-From: Stefan Baur <X2Go-ML-1@baur-itcs.de>
Resent-To: x2go-dev@lists.x2go.org
Resent-CC: X2Go Developers <x2go-dev@lists.x2go.org>
X-Loop: owner@bugs.x2go.org
Resent-Date: Sun, 14 Dec 2014 22:40:01 +0000
Resent-Message-ID: <handler.701.B.141859669621656@bugs.x2go.org>
Resent-Sender: owner@bugs.x2go.org
X-X2Go-PR-Message: report 701
X-X2Go-PR-Package: x2goclient
X-X2Go-PR-Keywords: 
Received: via spool by submit@bugs.x2go.org id=B.141859669621656
          (code B); Sun, 14 Dec 2014 22:40:01 +0000
Received: (at submit) by bugs.x2go.org; 14 Dec 2014 22:38:16 +0000
X-Spam-Checker-Version: SpamAssassin 3.3.2 (2011-06-06) on
	ymir.das-netzwerkteam.de
X-Spam-Level: 
X-Spam-Status: No, score=-1.9 required=5.0 tests=BAYES_00 autolearn=ham
	version=3.3.2
X-Greylist: delayed 302 seconds by postgrey-1.34 at ymir.das-netzwerkteam.de; Sun, 14 Dec 2014 23:38:14 CET
Received: from mout.kundenserver.de (mout.kundenserver.de [212.227.17.10])
	by ymir.das-netzwerkteam.de (Postfix) with ESMTPS id A14035DB1C
	for <submit@bugs.x2go.org>; Sun, 14 Dec 2014 23:38:14 +0100 (CET)
Received: from [192.168.0.3] ([188.105.123.110]) by mrelayeu.kundenserver.de
 (mreue103) with ESMTPSA (Nemesis) id 0M4Bbn-1Xica4447X-00rsjN; Sun, 14 Dec
 2014 23:33:12 +0100
Message-ID: <548E1038.9010807@baur-itcs.de>
Date: Sun, 14 Dec 2014 23:33:28 +0100
From: Stefan Baur <X2Go-ML-1@baur-itcs.de>
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:31.0) Gecko/20100101 Thunderbird/31.3.0
MIME-Version: 1.0
To: submit@bugs.x2go.org
CC: Michael DePaulo <mikedep333@gmail.com>, 
 Mike Gabriel <mike.gabriel@das-netzwerkteam.de>
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: 8bit
X-Provags-ID:  V03:K0:jbdJby9rZ7vJGOpCEduMPzy5Dk/ygY5Z/eoP+pcj9AWu92wMtD2
 dc1pY2fvEbGZccgfkBSGDgU8T/jBaIrQ7MuQIXZvCsccZdhpaSN20oCggDwlfJcCqiGRfbT
 sKJvBdgwBR3D008rVtqztX4CfQ50J4sypIHTXo50M6Gl5WQ/RGZNArbJ5UoBZh/2ffVazAk
 Tq4m7nW7jqTg7AGvgmf+Q==
X-UI-Out-Filterresults: notjunk:1;

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Package: x2goclient

Hi,

This was inspired by Mike#2's question on how to make microphone input
configurable in X2GoClient.  The real issue goes way deeper, IMO.

Basically, we have three places where an option (not only the
microphone input) could be set:

1) command line option
2) "forced" config from broker
3) sessions file (which may be on a read-only network share)

a) We need to define an order of precedence for each option; also,
   how to deal with conflicting options.

   Example 1: For the microphone to be enabled, both the command line
   option as well as the sessions file/broker config should match.
   If the command line option says --mic=off, and the sessions
   file/broker config says "mic=on", then the mic should be *off*.
   Also, if the the sessions file/broker config says "mic=off", then
   the command line option should *not* be able to override that.
   Only if one side indicates that it doesn't care (by lacking the
   option), or if all sides agree, the microphone should be turned on.
   This is a security/privacy-related issue.

   Example 2: The sessions file or the broker may specify cinerama=off,
   and now the user attaches a second screen.  So being able to pass a
   cinerama=on on the command line would be nice.  Also, this has no
   security/privacy implications (as far as I can tell - but feel free
   to prove me wrong), so an agreement between all sides (command line
   vs. sessions file/broker) would not be neccessary, as long as we
   agree on an order of precedence and document that properly.

b) The broker should be able to offer forced options as well as
   user-selectable options.  Think of it like the Firefox preferences
   configuration: Admins may, e.g., force the use of a proxy using a
   "lockPref", but they can also set a default home page that still
   *can* be overriden by the user ("user_pref").
   Similarly, the broker should be able to deliver a config (and the
   client should be able to parse it) that contains markers as to which
   settings are "locked" and which settings may still be changed by the
   user.
   Of course, this doesn't protect against "rogue" clients that have
   this feature disabled, so it's not a security measure, but it would
   allow an admin to, e.g., specify that sound is off by default, but
   the user may turn it on if so desired.

Mike#1: Feel free to clone this bug for the broker part.

- -Stefan

- -- 
BAUR-ITCS UG (haftungsbeschränkt)
Geschäftsführer: Stefan Baur
Eichenäckerweg 10, 89081 Ulm | Registergericht Ulm, HRB 724364
Fon/Fax 0731 40 34 66-36/-35 | USt-IdNr.: DE268653243
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.22 (MingW32)

iQEcBAEBAgAGBQJUjhA4AAoJEG7d9BjNvlEZHbgH/1jzw3GOkDuMVV83RfEVMTPi
h+pYBcifUYF/XUG+rGmiTAwvlmoUzgDNlOkbMhfuWJTP9ZwEMtGu3b6mbjEq5af6
5xB5OThtfgryF4DepfoRDeqyVzfLEH7/l43aP8IH08OJVtkiumNSfPvCoflP+IrM
dZzufEYdxPF1lazWInXb8cqtcGMB3pNGQSqenWTXDSYdh9hEK0quHv/8F23eo4gg
Wgu3FZumBQ5ZsmKIuYzzUJARDK+d8Qf1iW79rm9sMy239gCIdRiJ5Deq3rnHPEcS
2a4/1YwstCTMt/bCBwnl4CwssexWBj1vN3emvFhmz8cgGOgs6FXj3BnRX8Pf/G4=
=y3d1
-----END PGP SIGNATURE-----

Send a report that this bug log contains spam.