Subject: We need to talk about, and document, which options are overridable in which way

From: Stefan Baur <[email-masked]>
Date: Sun, 14 Dec 2014 23:33:28 +0100

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