Bug 241347 - security/sssd: Update to 1.16.4
Summary: security/sssd: Update to 1.16.4
Status: New
Alias: None
Product: Ports & Packages
Classification: Unclassified
Component: Individual Port(s) (show other bugs)
Version: Latest
Hardware: Any Any
: --- Affects Some People
Assignee: freebsd-ports-bugs mailing list
URL:
Keywords:
Depends on:
Blocks: 240708
  Show dependency treegraph
 
Reported: 2019-10-19 22:00 UTC by lukas.slebodnik
Modified: 2019-11-08 06:47 UTC (History)
3 users (show)

See Also:


Attachments
Update to 1.16.4 (84.01 KB, patch)
2019-10-19 22:00 UTC, lukas.slebodnik
no flags Details | Diff

Note You need to log in before you can comment on or make changes to this bug.
Description lukas.slebodnik 2019-10-19 22:00:39 UTC
Created attachment 208428 [details]
Update to 1.16.4

sssd-1.13 branch should have been LTM in upstream but latest version 1.13.4 is 2.5 years old.

sssd-1.16 branch is more suitable for the update.
Comment 1 Rick 2019-10-20 07:23:06 UTC
Reconsider defining an explicit Samba dependency. This factored into LDB conflicts between security/sssd and net/samba4* in the first place. Ports defines behavior for selecting the Samba version by setting a default that can be over-ridden via DEFAULT_VERSIONS, which puts greater control in the users hands.

Explicit dependency mitigates current behavior, but when net/samba411 is added to ports and users want to install 4.11 as opposed to 4.10, it requires overriding SMB_LIB_DEPENDS instead of using DEFAULT_VERSIONS like "DEFAULT_VERSIONS=samba=4.11".

Addressing the current failing behavior is achievable through a note in Makefile or UPDATING explaining net/samba410 to be the minimum Samba version required for SMB support. So, users know to deploy a configuration similar to that described in bug #238465.

Also, the SSSD project is shipping version 2.2. Are there compelling reasons for not updating to the project's most recent version, or at least adding it as a new port, security/sssd2 for example?
Comment 2 Rick 2019-10-20 08:18:32 UTC
Attached patch appears to fail citing the following. The config.log is at https://pastebin.com/Bc5ydiPH


checking for python2... no
checking for python3... no
configure: error: 
The program python3 was not found in search path.
Please ensure that it is installed and its directory is included in the search
path. It is required for building python3 bindings. If you do not want to build
them please use argument --without-python3-bindings when running configure.
===>  Script "configure" failed unexpectedly.
Please report the problem to lukas.slebodnik@intrak.sk [maintainer] and attach
the "/wrkdirs/usr/ports/security/sssd/work/sssd-1.16.4/config.log" including
the output of the failure of your make command. Also, it might be a good idea
to provide an overview of all packages installed on your system (e.g. a
/usr/local/sbin/pkg-static info -g -Ea).
*** Error code 1

Stop.
make: stopped in /usr/ports/security/sssd
=>> Cleaning up wrkdir
===>  Cleaning for sssd-1.16.4_1
build of security/sssd | sssd-1.16.4_1 ended at Sun Oct 20 04:06:08 EDT 2019
build time: 00:01:03
!!! build failure encountered !!!
Comment 3 Phillip R. Jaenke 2019-10-20 14:14:59 UTC
Rick, not speaking for Lukas here obviously, but I am speaking as someone very familiar with sssd. The "latest" is often "too latest." Frequently does not do what it says on the tin, at best. It's focused on feature addition and the like. Hence, why they have LTMs. The LTMs are tied to RHEL.
So from the FreeBSD side, the port should track what sssd version is in the current mainstream release of Red Hat. For 7.7, that's 1.16. I'm a large RHEL customer at $dayjob and the in-house sssd expert there, so I'm reasonably familiar with this. 

All that said, Lukas, can this build with python3.6+? FreeBSD is EOL'ing 2.7 much more aggressively than RH. So I would recommend building only with 3.x if possible so it doesn't come up as broken in January.

The other concern I have is around the security/krb5 and samba dependency. We don't have a good way to enforce option dependencies in other ports. I think this can be worked around by depending on ${LOCALBASE}/lib/shared-modules/krb5/winbind_krb5_localauth.so and ${LOCALBASE}/lib/samba4/krb5/plugins/kdb/samba.so which are only present when GSSAPI_MIT is selected in samba48+. That SHOULD prevent user foot-shooting by installing a GSSAPI_BUILTIN samba48+ against sssd here.
Comment 4 lukas.slebodnik 2019-10-21 10:12:43 UTC
(In reply to Rick from comment #1)
> Also, the SSSD project is shipping version 2.2. Are there compelling reasons for not updating to the project's most recent version, or at least adding it as a new port, security/sssd2 for example?

You would need to follow upstream closer to know the context.

There is not any sssd-2.0 or sssd-2.1 branch and thus they cannot bachport fixes there. And there were 2 regressions quite serious regressions between 2.2.0 and 2.2.2 

Upstream promised to make sssd-1.13 LTS version but reality is different.
CVE-2019-3811 (https://pagure.io/SSSD/sssd/issue/3901) was fixed just in master and sssd-1-16 branch. Sure, we could backport patches ourselves. but it is more complicated to backport patches from sssd-1.16 branch to sssd-1.13.

The sssd-1-13 branch had the latest commit 14 months ago and sssd-1-16 11 days ago.

I am not sure whether adding security/sssd2 make a sense.
I would rather wait till sssd-2.x stabilize on Linux and then move from sssd-1.16 to sssd-2.x. So far sssd-1-16 is still in "active" state in usptream.
Comment 5 lukas.slebodnik 2019-10-21 10:18:22 UTC
(In reply to Phillip R. Jaenke from comment #3)
> All that said, Lukas, can this build with python3.6+? FreeBSD is EOL'ing 2.7 much more aggressively than RH. So I would recommend building only with 3.x if possible so it doesn't come up as broken in January.

My patch enforce python3 and disable python2 by default.
Upstream tests python3.4+ so python3.6 should be fine

I would probably need to update port to not rely on pyhton3 but directly use python3.6. Is that what you want?

> The other concern I have is around the security/krb5 and samba dependency. We don't have a good way to enforce option dependencies in other ports. I think this can be worked around by depending on ${LOCALBASE}/lib/shared-modules/krb5/winbind_krb5_localauth.so and ${LOCALBASE}/lib/samba4/krb5/plugins/kdb/samba.so which are only present when GSSAPI_MIT is selected in samba48+. That SHOULD prevent user foot-shooting by installing a GSSAPI_BUILTIN samba48+ against sssd here.

Do I understand that you worry about mixing MIT krb5 and heimdal when building with samba ?
Comment 6 lukas.slebodnik 2019-10-21 10:29:13 UTC
(In reply to Rick from comment #1)
> Reconsider defining an explicit Samba dependency. This factored into LDB conflicts between security/sssd and net/samba4* in the first place. Ports defines behavior for selecting the Samba version by setting a default that can be over-ridden via DEFAULT_VERSIONS, which puts greater control in the users hands.

Situation with LDB is different samba is more picky about version of ldb.
sssd can work without recompilation with ldb 1.2, 1.3, 1.4, 1.5
The only exception is ldb-1.1.30 due to ABI breakage in ldb.


> Explicit dependency mitigates current behavior, but when net/samba411 is added to ports and users want to install 4.11 as opposed to 4.10, it requires overriding SMB_LIB_DEPENDS instead of using DEFAULT_VERSIONS like "DEFAULT_VERSIONS=samba=4.11".

The tricky part is winbind_idmap_sss.so The might change ABI between versions
and thus you need to recompile the plugin and to "downgrade" version with --with-smb-idmap-interface-version=6

Sure that module needn't be used by anyone and ipa and ad provider would work.
But it is dangeroups therefore I decided to stick with samna-4.10


> Addressing the current failing behavior is achievable through a note in Makefile or UPDATING explaining net/samba410 to be the minimum Samba version required for SMB support. So, users know to deploy a configuration similar to that described in bug #238465.


which changes do you suggest after my explanation?
Comment 7 Rick 2019-10-21 17:17:47 UTC
Thanks for explaining 1.16 vs 2.x. It makes sense to track the same version being deployed in Red Hat.

In considering explicit Samba dependencies, my preference remains in favor of putting control in the users hands unless there is material information I am missing or misunderstanding. Explicit dependency works for users pulling in Samba as a direct consequence of sssd. However, users pulling in Samba as a consequence of sssd and one or more other ports may experience conflicts and/or failed builds.

Defining explicit dependencies also implies more effort to ensure compatibility. In other words, ports defining explicit dependencies must stay vigilant as Samba versions are deprecated. SSSD fell victim to this as Samba 4.[678] have and are reaching EOL as proven by its failure to build w/ SMB from July 2019 on after Samba 4.[67] were removed and thus defaults to 4.8.

Comments to Makefile or UPDATING explaining and recommending defining default Samba to 4.10 when SMB is enabled are appropriate w/ the addition that changing the default may result in undesirable behavior as a consequence of differing ABIs with winbind_idmap_sss.so. This is irrelevant to me as each repository stands on it’s own.

Having said all that, sssd w/ the attached patch for 1.16.4 continues to fail during configure citing the error above. It occurs even despite defining PYTHON_VERSION and/or PYTHON_CMD in make.conf for either Python 2.7 or 3.6 like:

.if ${.CURDIR:M*/security/sssd}
PYTHON_VERSION= 3.6
PYTHON_CMD=/usr/local/bin/python3.6
OPTIONS_FILE_SET+=SMB  
.endif
Comment 8 lukas.slebodnik 2019-10-21 21:20:49 UTC
(In reply to Rick from comment #7)
> Comments to Makefile or UPDATING explaining and recommending defining default
> Samba to 4.10 when SMB is enabled are appropriate w/ the addition that changing
> the default may result in undesirable behavior as a consequence of differing
> ABIs with winbind_idmap_sss.so. This is irrelevant to me as each repository
> stands on it’s own.

That's not really true.
winbind_idmap_sss.so is plugin for winbind to use idmapping of SID -> (UIG/GID) done by sssd. (samba and winbind use different algorithms)
And as I already mentioned the ABI for plugins is not very stable.
Therefore I decided to stick to samba 4.10

Sure the best would be more flexible and be able to build with 4.10 and 4.11
(cause one is in maintenance mode and another in stable release)
https://wiki.samba.org/index.php/Release_Planning_for_Samba_4.11

But i would like to enforce strict runtime dependencies between samba and sssd.
Use the same version as were used at build time. And because of this I decided to stick with samba 4.10 

Could you point me to other ports which have similar requirements
about build-time and run-time dependencies for different ports?

> Having said all that, sssd w/ the attached patch for 1.16.4 continues to fail
> during configure citing the error above. It occurs even despite defining
> PYTHON_VERSION and/or PYTHON_CMD in make.conf for either Python 2.7 or 3.6 like:
>
> .if ${.CURDIR:M*/security/sssd}
> PYTHON_VERSION= 3.6
> PYTHON_CMD=/usr/local/bin/python3.6
> OPTIONS_FILE_SET+=SMB  
> .endif

That is a different bug which will be addressed.

But I would like get an agreement about samba.
Comment 9 Rick 2019-10-22 00:06:04 UTC
(In reply to lukas.slebodnik from comment #8)

Ok. I understand. Fortunately, it is a workable config.
Comment 10 Phillip R. Jaenke 2019-10-23 18:28:32 UTC
> I would probably need to update port to not rely on pyhton3 but directly use python3.6. Is that what you want?

Definitely not; I just saw the python2 and was worried it might be attempting to use that. ports should still have 3.4+ for quite some time, so the flavors method (and SHEBANGFIX) that Rick mentioned would be the best way there.

> Do I understand that you worry about mixing MIT krb5 and heimdal when building with samba ?

Yes, this is a known issue we ran into back on 1.13 when it was working cleanly if you don't recall. By default, FreeBSD samba4x uses the built-in Heimdal due to AD_DC being a default option. So a user taking samba48 or samba410 from pkg.freebsd.org and building security/sssd locally will end up with a broken sssd. samba48+ now has the option for MIT due upstream updates, but it's a non-default option on FreeBSD. So some additional care needs to be taken in the context of FreeBSD. Basically the security/sssd port should tell the user that the MIT option is required on their samba48 or samba410.

> The tricky part is winbind_idmap_sss.so The might change ABI between versions
and thus you need to recompile the plugin and to "downgrade" version with --with-smb-idmap-interface-version=6

> Sure that module needn't be used by anyone and ipa and ad provider would work.
But it is dangeroups therefore I decided to stick with samna-4.10

I would argue that it is a LOT more dangerous to NOT have the AD provider. I don't think the IPA provider is going to work correctly anyways (but it has been a while and I don't have a test environment handy.) But the AD provider is basically the number one use case on FreeBSD. So not having it working is going to be a LOT worse than people having Samba without MIT kerberos.

The Samba API changes absolutely make it a challenge and a half though, ESPECIALLY because net/samba410 is Schroedinger's Port: both broken and working. And both with built-in ldb and ldb1.5 (I think, I'd have to look again.) And in a lot of flux because AD_DC provisioning is broken plus folks attempting to fix it on ZFS again. That really throws a wrench into the works. 

Rick, do you know of an approved or at least not-horrible way to do CONFIG+=--with-smb-idmap-interface-version=6 based on the DEFAULT_VERSIONS value for samba?
Comment 11 Rick 2019-10-23 21:07:26 UTC
(In reply to Phillip R. Jaenke from comment #10)

> do you know of an approved or at least not-horrible way to do
> CONFIG+=--with-smb-idmap-interface-version=6 based on the
> DEFAULT_VERSIONS value for samba?

I pondered this, but didn't have an answer. The challenge being that there already is a default samba and the question is 'how does one tell if the version defined is implicit vs user defined?'.
Comment 12 Rick 2019-11-07 12:36:54 UTC
Lukas, is there an updated patch that needs testing? Updating the port is important to mature its security posture.
Comment 13 lukas.slebodnik 2019-11-07 20:47:45 UTC
Sorry,
I have a longer holiday ATM. I should be able to find time for update at weekend (or maybe on Monday) I am sorry for delay.
Comment 14 Phillip R. Jaenke 2019-11-08 06:47:56 UTC
No worries on that, we all have lives.

Since SSSD has *always* been a "special handling required" port, I think the only real question here is whether to ship as-is (which means default builds of dependencies will leave it non-functioning) or update samba410 to use MIT default (that's a timur@ call and as MIT is experimental probably a bad idea.)

Considering all those moving pieces, I think we've re-exposed a shortcoming in ports infrastructure that isn't going to be resolved today - or this quarter, and probably not next year. Once building clean is confirmed and function is confirmed when dependencies are built to suit, commit it as is. Then exclude it from official pkgbuilds (maybe RESTRICTED?) so that users have to engage their brains and build everything the right way.

Once we have the key portions here, I'm happy to take up the torch of writing a pkg message explaining to users what they need to do to produce a working setup.