Added user connection support to systemwide branch

[Andrey Borzenkov]

On Fri, Mar 25, 2011 at 4:30 AM, Lamarque Vieira Souza
<lamarque at gmail.com> wrote:
> Em Thursday 24 March 2011, Andrey Borzenkov escreveu:
>
>> I added initial user connections support on top of gokcen branch; it
>
>> is available for review here:
>
>>
>
>> git://anongit.kde.org/clones/networkmanagement/borzenkov/networkmanagement
>
>> in branch systemwide
>
> Is gokcen still working on networkmanagent code?
>

I do not know. He did not answer my e-mails.

>> Branch is merged with current master (sans couple of latest commits).
>
>> User connections seem to work as well as displaying systemwide
>
>> connections. I have not yet really tested write support for systemwide
>
>> as our default system plugin does not support writing (not really at
>
>> least).
>
> What do you mean by "default system plugin"? Do you mean the plugins line in
> /etc/NetworkManager/nm-system-settings.conf file?

Yes.

> I still do not understand
> exactly how that works.
>

Plugins are responsible for maintaining stable storage for connections
systemwide. They appeared as helpers to migrate from legacy networking
management to NM. On start NetworkManager loads plugin(s) listed in
configuration file and asks each to enumerate connections it knows
about. When user changes such connection (which of course requires
proper authorization) plugin is asked to commit it to stable storage.
Additionally plugins may assist in host name changes.

They are implemented as plugins because format of connection
definition varies greatly between different distributions. Not all
plugins are capable of persisting connections - so while you can
continue to use whatever was configured by system management
application(s), you won't be able to create new connections using NM.
For this reasons multiple plugins are supported; the first one that
supports writing will persist connection. Default one - keyfile -
comes with NM and always supports full semantic and became foundation
for connection storage in NM 0.9. I just need to setup it :)


>> I had to step back from initial design which was aimed at unifying
>
>> system and user connection and fetching all of them from kded via
>
>> dbus. One issue for me is authorization - user settings service is on
>
>> system bus, so adding Update method to it need to somehow validate
>
>> user. Another - it required a bit more knowledge of (KDE) D-Bus
>
>> implementation than I have right now :) So I just added back direct
>
>> connection loading, moving it a bit up into connection widget.
>
> The current code for user connections already asks for users secrets
> (username, password, encryption key, etc) even with NM's user settings
> interface residing in the system bus. Can't you try to reuse that code?

That is different codepath and will survive (although probably not in
the same form) in NM 0.9 as well as part of user secrets agent. It is
on my todo list to split secrets persistence so it can be reused by NM
0.9 code as well. Usage is already segregated (i.e. we almost always
load connection settings and secretes separately).

Once more

- user settings service is present on system bus
- D-Bus allows following policies for controlling permissions to call
method: at_console or specific user(s) (root being subclass of
"specific user(s)")
- the policy is set by a single systemwide file and does not change

So to allow any user to modify own settings via D-Bus (at least, using
standard user settings service as was intended) Update methods would
need to be set read-write for all. And implement authorization itself.

Alternative is to create separate class for processing Update requests
and listes on session bus. So we will ListConnections via one
interface and Update via another. This complicates implementation for
no real benefit - user settings are dead end anyway.

> What
> do you need to know about KDE's DBus implementation? KDE programs usually
> uses Qt DBus module directly or create a wrap around it, like
> Solid::Control::* classes. I usually use Qt DBus documenation when I need.
>

Sure. It is just that it makes it far harder for me to debug and as I
said I wanted to have working PoC early enough.

>> User connections are actually relatively good localized - there are
>
>> just two entry points: kded and connections widget. The latter looks
>
>> absolutely ugly, but I wanted to have working prototype before
>
>> starting to clean it up.
>
>>
>
>> I would like to ask whether this *may* be accepted. I am not sure how
>
>> to prepare patch got reviewboard; may be patch relative to merge point
>
>> is OK?
>
> I think a patch relative to git://anongit.kde.org/networkmanagement master
> head would be simpler for someone to apply it and test.
>

OK I will do.