[MIR] sssd

we just did avoid promoting libev, having libevent already in main. libverto in main does provide an abstraction layer for all these event libraries. please check to use either libverto, or libevent directly.

libverto or libevent don't provide integration for talloc, which is one of the key features of libtevent.

At the very least you would need a wrapper layer in libldb and sssd around libevent or libverto.

Samba 4/OpenChange/Evolution-mapi (in universe) also rely on tevent and the fact that libldb uses it. They would have to be patched to use the same event library libldb uses or compiled against a fork of libldb without the patch.

About the libsemanage dependency; as far as I understand, it's only needed if the host is using SELinux together with sssd configured with a 'local' domain (so that pam_sssd handles local accounts). So if we are not interested in fully supporting SELinux in main, the build-dep could be dropped.

ding-libs should be simple, it's just libs that used to be part of sssd but split as an external package so others can use them too.

Notes from upstream:

1) The libsemanage dependency can be dropped by passing --without-semanage as an argument to configure. (Similarly, we also have a --without-selinux option that removes the other SELinux features used by the sss_[user|group]_* tools.) These features are available so that when creating users and groups in an SELinux-enabled system, they are always created with the proper security contexts as defined by the system policy.

2) tevent is inextricable from SSSD. We cannot switch to libverto because both SSSD and LDB rely on native features of tevent (specifically its integration with talloc for managing easy cancellation of events) that are simply not available in the standard libverto instance. If you're interested in the reasoning, I wrote a blog post about it almost two years ago: http://sgallagh.wordpress.com/2010/03/17/why-you-should-use-talloc-for-your-next-project/

libverto is a useful tool for use as a general-purpose mainloop interface, but there will always be cases of projects that prefer to use specific loops for the additional features it can offer.

Unattaching from https://blueprints.launchpad.net/ubuntu/+spec/servercloud-p-sssd-mir to fix WI tracker

Status changed to 'Confirmed' because the bug affects multiple users.

looks like the issue about tevent has been replied.

Security review:

While there have been CVEs, they were fixed in a reasonable amount of time and with minimal code changes. Upstream is responsive as well. Redhat and Fedora have sssd in there repos and they receive security updates, so we can coordinate with others. Interestingly, rhel6 and Debian still have sssd 1.2.

I spot checked the code and it is coded well and defensively.

There are no compiler warnings or errors in the build

Once configured, there is a long-running root daemon, but based on upstream documentation and initial configuration, it does not listen over the network (though it obviously makes connections over the network). The daemon must necessarily run as root to perform authentication duties. There are a number of userspace tools that must be run as root to manage users.

sssd also has a test suite that is enabled during the build, though there is this interesting tidbit from configure:
checking for CHECK... no
configure: WARNING: Without the 'CHECK' libraries, you will be unable to run all tests in the 'make check' suite

There is DBus integration, but AIUI it is on a private bus and not accessible to non-root processes.

It would be nice to have those additional tests enabled in the build, but it is not a condition of this MIR.

ACK for sssd.

As for libsemanage, it requires libustr-dev to also be promoted. ustr is a small library with no CVE history, but has a lot of compiler warnings that I would like to see fixed before it was considered for main inclusion. But beyond that, Ubuntu does not have a strong SELinux community around it, so while I would like to be able to have sssd have full SELinux support, I don't think it is appropriate to promote libsemanage at this time.

"Interestingly, rhel6 and Debian still have sssd 1.2." This is not true about RHEL 6 (exactly). RHEL 6.0 shipped with SSSD 1.2, but RHEL 6.1 and 6.2 shipped with SSSD 1.5. Our expectation is for RHEL 6.3 to update to SSSD 1.8.0 (the upcoming upstream LTM release). Each Fedora release sees the latest upstream SSSD release (we are now timing the minor version releases to be every three months, so Fedora releases will get every even-numbered minor version).

You are correct that SSSD uses libdbus, but for internal communication only (between the responders and data providers, and between the "watchdog" process and all the SSSD children).

We use check (http://check.sourceforge.net/) for the vast majority of our unit tests. In upstream, Fedora and RHEL we require all of these tests to pass as a condition of inclusion. It would be nice if Ubuntu could include 'check' in its build-system, even if not included in the released distribution. But as you noted above, the build as a whole does not rely on the test suite being fully-functional.

As for upstream being responsive, I hope this qualified :)

Jamie, thank you for the review!

Debian will have 1.5.16 as soon as I've passed the Debian Maintainership process, if not uploaded by a sponsor earlier. I'm also hopeful that squeeze will get 1.8.x which is what I'm preparing for precise as well, since it's the next LTM release as Stephen pointed out.

I've now added 'check' as a build-dependency, and ran it through sbuild and saw that tests are being run and all passed. It's committed to debian git, we'll get it for the next upload.

Hi Timo, Jamie,

On 02/10/2012 08:22 PM, Timo Aaltonen wrote:
> Jamie, thank you for the review!
>
> Debian will have 1.5.16 as soon as I've passed the Debian Maintainership
> process, if not uploaded by a sponsor earlier. I'm also hopeful that
> squeeze will get 1.8.x which is what I'm preparing for precise as well,
> since it's the next LTM release as Stephen pointed out.
>
> I've now added 'check' as a build-dependency, and ran it through sbuild
> and saw that tests are being run and all passed. It's committed to
> debian git, we'll get it for the next upload.
I'm happy to sponsor if that would be useful.

Cheers,

Jelmer

Jelmer, that would be great. I'll ping you early next week. Ding-libs needs to go first and sssd after that.

ps. I have a whole lot of other packages too if you're interested to sponsor them (389ds, freeipa related) ;)

On 02/10/2012 09:30 PM, Timo Aaltonen wrote:
> Jelmer, that would be great. I'll ping you early next week. Ding-libs
> needs to go first and sssd after that.
Cool - I'm 'jelmer' on IRC.
> ps. I have a whole lot of other packages too if you're interested to
> sponsor them (389ds, freeipa related) ;)
Let's start with ding-libs and sssd. I might be able to sponsor more,
but I'm not sure how much time I will have later in the Ubuntu cycle.

Cheers,

Jelmer

Stephen,

""Interestingly, rhel6 and Debian still have sssd 1.2." This is not true about RHEL 6 (exactly)." Ah, that is reassuring. I must have looked at an old manifest. Thanks for clarifying that point.

"As for upstream being responsive, I hope this qualified :)" I would say so. Thanks! :)

BTW, while not a condition of this MIR, it sounds like sssd would be a great candidate for an apparmor profile-- runs privileged and processes network traffic but its actions are well known and predictable. If someone is up for it, feel free to ask for help in #ubuntu-hardened on Freenode or #apparmor on OFTC.

yeah adding a profile for apparmor is a good idea, I'll add a bug about it.

Didier, can you look at the rest of this set of MIRs? (Jamie did the security-sensitive one it looks like.)

Ok, finally having the time to look at it, here is my feedback:
- apparmor profile will greatly be appreciated (if not done already),
- dropping semanage buil-dep and using --without-semanage would be appreciated seeing the implication of it and the new build-dep it introduces having compiler warnings.
- for the remaining build-dep (as the tevent discussion was sorted), I would appreciated pointers to MIR bugs (with the full rationale, build-dep check, quality package check) for the 3 others introduced build-dep in main:
* ding-libs (libcollection-dev, libini-config-dev, libdhash-dev)
* tevent (libtevent-dev)
* ldb (libldb-dev)

Please, reassign to me once done :)

Adding samba4 to the mix, as the new PAC responder needs it. It's currently disabled from the package, but I'll re-enable once R opens.

Also, I'd rather just sync it from Debian if we could get libsemanage in main as well. There's no other diff than what's caused by the rather artificial main/universe split.

Status changed to 'Confirmed' because the bug affects multiple users.

Note that samba4 build-depends on some packages that are not in main, most notably subunit (MIR @ bug 780767), heimdal and libparse-yapp-perl.

FYI, I just ACK'd ustr and libsemanage in bug #1077484.

Any chance of getting this MIR done for libnl? The new version of netcf won't build until libnl is in main: https://launchpad.net/ubuntu/+source/netcf/1:0.2.0-5

As for the rest of the packages, Didier asked earlier:

"""
- for the remaining build-dep (as the tevent discussion was sorted), I would appreciated pointers to MIR bugs (with the full rationale, build-dep check, quality package check) for the 3 others introduced build-dep in main:
* ding-libs (libcollection-dev, libini-config-dev, libdhash-dev)
* tevent (libtevent-dev)
* ldb (libldb-dev)
"""

Can you either point at the separate MIR bugs or expand this bugs description to include info on all the dependencies?

libsemanage is in main now

closing the libnl task, sssd 1.10 will build against libnl3 anyway, and looks like netcf got fixed as well

no need to move samba4 in main, we'll need to merge samba 4.0.x from debian instead

Didier, can you look at this bug again and figure out what needs to happen next?

Well, I still need to file a MIR for libpwquality, and a separate one for ding-libs if needed (it got split off sssd some time ago)

and actually, when the new samba is merged ldb will move to main, so having it here is probably unnecessary

samba 4.0.10 is now in depwait (due to ldb, libparse-yapp-perl, faketime)

dropped ldb from here, it has a MIR of it's own: https://bugs.launchpad.net/ubuntu/+source/ldb/+bug/1250463

and now ding-libs has one too: https://bugs.launchpad.net/ubuntu/+source/ding-libs/+bug/1250467

..and libpwquality already had an old MIR where the pam-module was not promoted at that time, but I've reopened it now:

https://bugs.launchpad.net/ubuntu/+source/libpwquality/+bug/1017285

Hum, I just ran check-mir on sssd and it seems quite some build-deps are still not in main with the latest release, Timo can you have look please?

 * libpam-dev does not exist (pure virtual?)
 * libdhash-dev binary and source package is in universe
 * libcollection-dev binary and source package is in universe
 * libini-config-dev binary and source package is in universe

 * libsasl2-modules-ldap is in universe, but its source cyrus-sasl2 is already in main; file an ubuntu-archive bug for promoting the current preferred alternative
-> I don't think that one will be an issue
 * libpam-pwquality is in universe, but its source libpwquality is already in main; file an ubuntu-archive bug for promoting the current preferred alternative
-> same, shouldn't be an issue (as per your other request)

Also, what is going to pull sssd to main, will it be directly seeded?
Thanks! Feel free to just reassign the MIR to me directly once you answered those questions

ok, forget about:
 * libdhash-dev binary and source package is in universe
 * libcollection-dev binary and source package is in universe
 * libini-config-dev binary and source package is in universe

they are all from djing-libs (not obvious from the name) ;)

However, there are still the 2 (now easy then) questions:
* libpam-dev does not exist (pure virtual?)
* what is going to pull it in main?

thanks for the review, now the answers;

libpam-dev is build-depended by 82 packages, but I've changed it in git now to use 'libpam0g-dev | libpam-dev'

I don't think this will be seeded (in the image?), it was just generally requested that SSSD to be moved in main to make it clear it's supported.

@Timo: something needs to "pin" sssd in main. So either seeding it in the supported seed or installed by default. It seems you want the first one, right?

Just waiting on djing-libs to be fixed/acked and if you agree with seeding that one to the support seed, I'll promote/do it.

Everything is green but samba4 (when I tried to seed it yesterday). Just ping me once the MIR is approved and I'll handle it.

On Tue, Nov 19, 2013 at 07:10:17AM -0000, Didier Roche wrote:
> Everything is green but samba4 (when I tried to seed it yesterday). Just
> ping me once the MIR is approved and I'll handle it.
The samba4 source package should no longer be necessary in trusty, just the samba source
package (which is in main already).

Jelmer

From my yesterday trying to seed sssd, there are some components mismatched:

  o samba4: libdcerpc-dev libdcerpc-server-dev libdcerpc-server0 libdcerpc0 libgensec-dev libgensec0 libndr-dev libndr-standard-dev libndr-standard0 libndr0 libparse-pidl-perl libregistry-dev libregistry0 libsamba-credentials-dev libsamba-credentials0 libsamba-hostconfig-dev libsamba-hostconfig0 libsamba-policy-dev libsamba-policy0 libsamba-util-dev libsamba-util0 libsamdb-dev libsamdb0 libsmbclient-raw-dev libsmbclient-raw0 libtorture-dev samba-dsdb-modules samba4-dev
    [Reverse-Depends: Rescued from samba4, libdcerpc-server-dev, libdcerpc0, libgensec0, libndr-standard0, libndr0, libregistry-dev, libsamba-credentials0, libsamba-policy-dev, libsamba-policy0, libsmbclient-raw-dev, samba4-dev, sssd-ad]
    [Reverse-Recommends: libsamdb0]
    [Reverse-Build-Depends: sssd]

the new samba is still in proposed, but I should probably upload a new sssd to build against samba-dev instead of the old packages

synced 1.11.1-1 from unstable, 1.11.2-1 will follow later.

1.11.1-1 drops the build-dep entirely or should I wait on 1.11.2-1?

It build-depends on samba-dev, which is all that the new samba package provides :) The old packages are no more.

as you see, it has built successfully:

https://launchpad.net/ubuntu/trusty/+source/sssd/1.11.1-1

so.. I realized that I could've synced 1.11.1-1 earlier, it was the first release to build with the new samba source package based on 4.0.x

Ok, I tried to seed it again, and I was thinking the seed would grab samba4 which is stuck in proposed, but it seems not:
  o samba4: libdcerpc-dev libdcerpc-server-dev libdcerpc-server0 libdcerpc0 libgensec-dev libgensec0 libndr-dev libndr-standard-dev libndr-standard0 libndr0 libparse-pidl-perl libregistry-dev libregistry0 libsamba-credentials-dev libsamba-credentials0 libsamba-hostconfig-dev libsamba-hostconfig0 libsamba-policy-dev libsamba-policy0 libsamba-util-dev libsamba-util0 libsamdb-dev libsamdb0 libsmbclient-raw-dev libsmbclient-raw0 libtorture-dev samba-dsdb-modules samba4-dev
    [Reverse-Depends: Rescued from samba4, libdcerpc-server-dev, libdcerpc0, libgensec0, libndr-standard0, libndr0, libregistry-dev, libsamba-credentials0, libsamba-policy-dev, libsamba-policy0, libsmbclient-raw-dev, samba4-dev, sssd-ad]
    [Reverse-Recommends: libsamdb0]
    [Reverse-Build-Depends: sssd]

Can you just give a sign when the transition ends and then, I'll do the third seeding (and hopefully working) seeding ;)

forget samba4, it's obsoleted by the new samba :)

samba, OTOH is stuck in proposed for other reasons, mainly bug #1250463 blocking it (AIUI) from moving out of proposed. But sssd got built against samba-dev which was right.

alrighty, the transition is now done and 1.11.2-1 built against the new samba, so seeding it should succeed now

Seeded it again and promoted sssd to main, we'll see what happens in c-m.

looking good!