[arch-general] netcfg wlan connection renewal

[Philipp Überbacher]

Excerpts from Fons Adriaensen's message of 2011-09-29 12:36:30 +0200:
> On Thu, Sep 29, 2011 at 11:51:53AM +0200, Tom Gundersen wrote:
> 
> > What you are seeing is udisks [0]. The policy that is implemented, if
> > I understand correctly, is that udisks allows a user who is physically
> > at the machine to mount the usb drive, but not remote users.
> > 
> > This makes sense for two reasons:
> > 
> > * A user who is physically present could just grab the usb stick and
> > insert it in a laptop where he/she has whatever permissions necessary
> > to do whatever they want, so no security is lost.
> 
> This makes no sense.  I don't mind if they use their own sticks
> on their own laptop. I do if they use it one this particular
> machine.
> 
> > * Furthermore, you probably don't want have to ask the admin to set up
> > a new entry in fstab for every usb drive that is plugged into your
> > machine.
> 
> Not necessary. Priveleges to do certain things are given
> per user or to groups, it's done when a user's account is
> set up and that's it. Sudo can handle this nicely. The fstab
> entries for my own usb disks are there mainly because they
> have dedicated mount points.
> 
> The last thing I want as an admin is a 'parallel administration'
> such as polkit, in particular if it can grant priveleges just
> by adding some files to a directory. That's very convenient for
> package managers etc. but it surely does not enhance security. 

A real-world example of 'configuration by adding files':
On a debian server, I needed more modules than usual early on, I needed
to recreate initramfs with all modules. Debian has a file to configure
how many modules are built into initramfs. I changed the config,
rebuilt, tested, and it didn't work. Let's say it took me a long while
to figure out what was going on. Years ago the debian installer asked my
predecessor about the policy for building modules into initramfs,
created a file with the config option and put it into a directory
somewhere. This file was overriding the main config file and cost me a
lot of time.
With a system like that you need to dig through lots of files to check
whether they could affect a configuration option. Even worse, there
could be multiple files affecting the same option, creating a precedence
chain that could be a lot of fun to figure out.
In my opinion, in this particular case, it would have been way smarter
to drop the installing sysadmin into a text editor with the
well-commented main config file. Nothing lost, except a lot of
frustration years later.
Configuration by adding files can create a jungle that's really hard to
see through, which can easily lead to miss-configuration. That the whole
thing is basically strap-on security in addition to the already built-in
security configuration of the system doesn't make it any better.