On Thu, Feb 17, 2011 at 04:09:36PM -0600, DRC wrote: > On 2/17/11 3:38 PM, Martin Koegler wrote: > > This decision has been commited by Adam in rev 4093 and 4094. > > > > He has ripped out the support switching between Client and Server > > security type order and set the default to client. > > (http://www.mail-archive.com/tigervnc-devel@lists.sourceforge.net/msg00721.html) > > > > I'm in favour of this change, as as enforment of server settings is a > > placebo in the open source world. > > The open source world and the real world aren't often the same thing. > :) In the real world, SysAdmins like to be able to steer user behavior, > even if they can't fully control it. I will concede that without the > ability to set the security types at the system level, using a security > config file, enforcing the server security type order is less > meaningful. However, I'm trying to lay the groundwork for the later > addition of a security config file. As I've said before, I'm not trying > to make the system hack-proof. I'm trying to make it mistake-proof-- to > provide a mechanism whereby SysAdmins can steer users toward a > particular mode of operation.
The traditional unix way of steering the user behaviour is the following settings preference: 1) Parameter specified on the command line 2) Parameter in the config file in $HOME 3) Parameter in the config file in /etc 4) Last fallback: compiled in defaults This way, the admin can set sytem defaults. He is still aware, that the users can override it and can take counter measures on a level, he has full control of [eg. firewall]. Your approach gives a false sense of security to clueless admins: They think, that they can control the behaviour and therefore avoid other security measures. Regards, Martin Kögler ------------------------------------------------------------------------------ The ultimate all-in-one performance toolkit: Intel(R) Parallel Studio XE: Pinpoint memory and threading errors before they happen. Find and fix more than 250 security defects in the development cycle. Locate bottlenecks in serial and parallel code that limit performance. http://p.sf.net/sfu/intel-dev2devfeb _______________________________________________ Tigervnc-devel mailing list Tigervnc-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/tigervnc-devel
