Patchwork [0/4] Upgrade connman to 1.0

login
register
mail settings
Submitter Ross Burton
Date May 29, 2012, 8:43 p.m.
Message ID <cover.1338323483.git.ross.burton@intel.com>
Download mbox
Permalink /patch/28893/
State New
Headers show

Pull-request

git://git.yoctoproject.org/poky-contrib ross/connman

Comments

Ross Burton - May 29, 2012, 8:43 p.m.
Below is a patch set upgrading connman to 1.0, and cleaning up the packaging somewhat.

It Works For Me, but my current available hardware is limited to qemux86 and
a headless Atom machine.  In particular the non-root-X permission changes
look to be correct (where they were previously obviously wrong) but I
haven't verified that they work.  Also the packaging has changed quite
dramatically since <0.79 becaus what used to be plugins is now in the core,
which has the potential to break any explicit dependencies on the plugin
packages.  I've added suitable RPROVIDES which should mitigate that.

(note that this is against poky master, not oe-core)

Ross

The following changes since commit f28209d9d3c67203a2c7a2b25cacfe31643d1bfa:

  cooker.py: terminate the Parser processes (2012-05-25 11:39:33 +0100)

are available in the git repository at:
  git://git.yoctoproject.org/poky-contrib ross/connman
  http://git.yoctoproject.org/cgit.cgi/poky-contrib/log/?h=connman

Ross Burton (4):
  connman: just give xuser the extra rights it needs
  connman: remove a deliberate sed that breaks all DBus access control
    for connman
  connman: respect the 3g feature and enable/disable ofono support
  connman: upgrade to 1.0

 meta/recipes-connectivity/connman/connman.inc      |   34 +++++++-----
 ...ange-visibility-to-default-for-debug-symb.patch |   35 ------------
 .../connman/add_xuser_dbus_permission.patch        |   14 ++---
 .../connman/connman/disable_alg-test.patch         |   46 ----------------
 .../connman/connman/ethernet_default.patch         |   22 --------
 .../connman/test-set-ipv4-method-api-fix.patch     |   50 ------------------
 .../connman/test-set-ipv6-method-api-fix.patch     |   55 --------------------
 meta/recipes-connectivity/connman/connman_0.79.bb  |   14 -----
 meta/recipes-connectivity/connman/connman_1.0.bb   |    9 +++
 9 files changed, 34 insertions(+), 245 deletions(-)
 delete mode 100644 meta/recipes-connectivity/connman/connman/0001-plugin.h-Change-visibility-to-default-for-debug-symb.patch
 delete mode 100644 meta/recipes-connectivity/connman/connman/disable_alg-test.patch
 delete mode 100644 meta/recipes-connectivity/connman/connman/ethernet_default.patch
 delete mode 100644 meta/recipes-connectivity/connman/connman/test-set-ipv4-method-api-fix.patch
 delete mode 100644 meta/recipes-connectivity/connman/connman/test-set-ipv6-method-api-fix.patch
 delete mode 100644 meta/recipes-connectivity/connman/connman_0.79.bb
 create mode 100644 meta/recipes-connectivity/connman/connman_1.0.bb
Koen Kooi - May 29, 2012, 8:56 p.m.
Op 29 mei 2012, om 22:43 heeft Ross Burton het volgende geschreven:

> Below is a patch set upgrading connman to 1.0, and cleaning up the packaging somewhat.
> 
> It Works For Me, but my current available hardware is limited to qemux86 and
> a headless Atom machine.  In particular the non-root-X permission changes
> look to be correct (where they were previously obviously wrong) but I
> haven't verified that they work. 

IIRC the sed was done to get around the 'atconsole' restriction, is that not needed anymore? E.g. can I ssh in as root and run the connman tests and when I log in to gdm as a simple user will connman-gnome work?

regards,

Koen
Ross Burton - May 29, 2012, 9:05 p.m.
On 29 May 2012 21:56, Koen Kooi <koen@dominion.thruhere.net> wrote:
> IIRC the sed was done to get around the 'atconsole' restriction, is that not needed anymore? E.g. can I ssh in as root and run the connman tests and when I log in to gdm as a simple user will connman-gnome work?

If that was the intention then it's a very heavy-handed solution...

Out of the box, root can access the service.  There is another patch
to add "xuser" for systems which run a raw X session as that user.  If
you're logging in with gdm to an arbitrary user, then the at_console
test should work, right?

(one of my plans is to remove hacks like this and have a lightweight
way of starting an X session as a normal user and actually registering
it as a session)

Ross
Koen Kooi - May 29, 2012, 9:20 p.m.
Op 29 mei 2012, om 23:05 heeft Burton, Ross het volgende geschreven:

> On 29 May 2012 21:56, Koen Kooi <koen@dominion.thruhere.net> wrote:
>> IIRC the sed was done to get around the 'atconsole' restriction, is that not needed anymore? E.g. can I ssh in as root and run the connman tests and when I log in to gdm as a simple user will connman-gnome work?
> 
> If that was the intention then it's a very heavy-handed solution...
> 
> Out of the box, root can access the service.  There is another patch
> to add "xuser" for systems which run a raw X session as that user.  If
> you're logging in with gdm to an arbitrary user, then the at_console
> test should work, right?

No, our PAM magic is still not strong enough :( And worse, serial console doesn't work with at_console either.
Ross Burton - May 29, 2012, 10:12 p.m.
On 29 May 2012 22:20, Koen Kooi <koen@dominion.thruhere.net> wrote:
>> Out of the box, root can access the service.  There is another patch
>> to add "xuser" for systems which run a raw X session as that user.  If
>> you're logging in with gdm to an arbitrary user, then the at_console
>> test should work, right?
>
> No, our PAM magic is still not strong enough :( And worse, serial console doesn't work with at_console either.

Damn shame - totally bust access control is quite depressing.  I'll
revert that chunk and throw a large comment around it - can't have
something some suspicious without any documentation.

Hopefully without sounding like an ex-MeeGo fanboy, uxlaunch is
actually pretty useful for this.  It sets up a proper PAM login,
brings up X, and handles XDG autostart.  Might be worth looking at for
single-user environments.

Ross
Cristian Iorga - May 30, 2012, 3:53 a.m.
Hi Ross,

As far as I have seen from the code, between the previous version of connman and version 1.0, the way the default connection is set has changed.

Right now, the default connection is established through an external file.
Before 1.0, the default connection was established via the code (and a patch was added in the recipe against this, and it needs to be adapted).

See bug regarding this:
Bug #2491
https://bugzilla.yoctoproject.org/show_bug.cgi?id=2491


-----Original Message-----
From: openembedded-core-bounces@lists.openembedded.org [mailto:openembedded-core-bounces@lists.openembedded.org] On Behalf Of Burton, Ross

Sent: Wednesday, May 30, 2012 6:13 AM
To: Patches and discussions about the oe-core layer
Subject: Re: [OE-core] [PATCH 0/4] Upgrade connman to 1.0

On 29 May 2012 22:20, Koen Kooi <koen@dominion.thruhere.net> wrote:
>> Out of the box, root can access the service.  There is another patch 

>> to add "xuser" for systems which run a raw X session as that user.  

>> If you're logging in with gdm to an arbitrary user, then the 

>> at_console test should work, right?

>

> No, our PAM magic is still not strong enough :( And worse, serial console doesn't work with at_console either.


Damn shame - totally bust access control is quite depressing.  I'll revert that chunk and throw a large comment around it - can't have something some suspicious without any documentation.

Hopefully without sounding like an ex-MeeGo fanboy, uxlaunch is actually pretty useful for this.  It sets up a proper PAM login, brings up X, and handles XDG autostart.  Might be worth looking at for single-user environments.

Ross

_______________________________________________
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core
Ross Burton - May 30, 2012, 9:53 a.m.
On 30 May 2012 04:53, Iorga, Cristian <cristian.iorga@intel.com> wrote:
> Hi Ross,
>
> As far as I have seen from the code, between the previous version of connman and version 1.0, the way the default connection is set has changed.
>
> Right now, the default connection is established through an external file.
> Before 1.0, the default connection was established via the code (and a patch was added in the recipe against this, and it needs to be adapted).

With 1.0, if there is no global configuration the technology is
enabled if ethernet, otherwise disabled.

Ross