Re: [RFC] Fast-user-switching plans

[Dan Williams <dcbw redhat com>]

On Sun, 2010-06-06 at 00:30 +1200, Simon Geard wrote:
> On Fri, 2010-06-04 at 19:24 -0700, Dan Williams wrote:
> > On Wed, 2010-06-02 at 23:44 +1200, Simon Geard wrote:
> > > On Wed, 2010-06-02 at 00:45 -0700, Dan Williams wrote:
> > > > The one benefit of user connections is that they follow you if you back
> > > > up your homedir and switch machines :)  I don't think that's enough of a
> > > > benefit to keep them around though.
> > > 
> > > Also if you periodically update your OS - e.g installing a new Ubuntu
> > > release every six months. Stuff in $HOME stays - stuff in /etc doesn't.
> > 
> > Yup.  Though we could mitigate that by providing usable backup/restore
> > capability that dumps a bunch of keyfiles describing your connections
> > into a tarball or something.
> 
> Is a user going to appreciate that, though? I.e, will they realise that
> their network settings are something that needs manually backing up? Or
> will they learn this out after installing an update, and finding they've
> lost the VPN settings they assumed were stored safely in $HOME?

I think it's unclear... some users would based on previous expectations.
If we make import/export work well we mitigate that.  But there are also
users for which this just doesn't matter because they don't go through
the trouble of rsyncing $HOME every time they switch machines.  It's
clear this is a downside of the decision though.

The question is, is it enough of a downside that it outweighs the
benefits?  That's a nuanced question but I think at this point my
impression is that the benefits are greater.  Namely, simpler
architecture is more flexible and allows easier creation of different UI
for different situations, which clearly benefits all users (this is the
"big one").  Second, this simplification reduces the number of
code-paths making future maintenance easier.  Third, it enables
fast-user-switching and multi-seat configurations which is something
that people have also been asking about for a long time.  Fourth, it
also enables better integrated network configuration editing and
creation from just about anywhere on the system.

Either way, it's important to understand all the tradeoffs in this sort
of decision.

> Actually, here's a thought - the login/password details for each
> connection are currently stored in the user's keyring. If you were to
> turn "user connections" into "system connections with ACL", how would
> that piece work? If system connections are removed or their permissions
> changed, are keys removed from the keyring?

That part depends on the connection; if secrets were pushed with the
connection when it was created, user secrets wouldn't be required.
However, there are cases where they would be desirable even if the
secrets were already stored for it.  In that case, we need to ensure we
get signaling right, but we need to do that anyway.

If the connection ACL is changed in such a way that certain users are no
longer able to use that connection, then one of two things happens... if
the user agent that has secrets already stored for that connection is
running, then it would remove the stored secrets.  If it is not running,
the secrets would stay in the keyring and could optionally be removed by
the user agent when the agent starts up the next time.

I think it's clear that even if there are no user connections as such,
that we still need secrets on a per-user basis for some connections.
And that's not actually that hard to do, and we've got most of the code
written for that already.

Dan