Added user connection support to systemwide branch

[Andrey Borzenkov]

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

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).

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.

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?

Regards

-andrey

[Lamarque Vieira Souza]

Post by Andrey Borzenkov
I added initial user connections support on top of gokcen branch; it
git://anongit.kde.org/clones/networkmanagement/borzenkov/networkmanagement
in branch systemwide

Is gokcen still working on networkmanagent code?

Post by Andrey Borzenkov
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? I still do not understand
exactly how that works.

Post by Andrey Borzenkov
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? 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.

Post by Andrey Borzenkov
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.

[Andrey Borzenkov]

On Fri, Mar 25, 2011 at 4:30 AM, Lamarque Vieira Souza

Post by Lamarque Vieira Souza

Post by Andrey Borzenkov
I added initial user connections support on top of gokcen branch; it
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.

Post by Lamarque Vieira Souza

Post by Andrey Borzenkov
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.

Post by Lamarque Vieira Souza
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 :)

Post by Lamarque Vieira Souza

Post by Andrey Borzenkov
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.

Post by Lamarque Vieira Souza
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.

Post by Lamarque Vieira Souza

Post by Andrey Borzenkov
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.