[Pkg-sssd-devel] sssd 2.9.5-5 MIGRATED to testing

[Andreas Hasenack]

Ok, this[1] makes the tests pass again with 2.10.1.


1. https://salsa.debian.org/sssd-team/sssd/-/merge_requests/37

On Mon, Jan 6, 2025 at 10:41 AM Andreas Hasenack
<andreas.hasenack at canonical.com> wrote:
>
> Ok, got more logs, looks like it's the new privilege handling via
> capabilities that is failing:
>
> * (2025-01-06 13:34:39): [krb5_child[5531]] [unpack_buffer] (0x0100):
> [RID#4] ccname: [FILE:/tmp/krb5cc_10001_XXXXXX] old_ccname: [not set]
> keytab: [not set]
> 1273
> * (2025-01-06 13:34:39): [krb5_child[5531]] [sss_set_cap_effective]
> (0x0400): [RID#4] cap_set_proc() failed: 1 ('Operation not permitted')
> 1274
> * (2025-01-06 13:34:39): [krb5_child[5531]] [privileged_krb5_setup]
> (0x0020): [RID#4] Failed to set real GID: 1
> 1275
> ********************** BACKTRACE DUMP ENDS HERE
> *********************************
> 1276
> (2025-01-06 13:34:39): [krb5_child[5531]] [main] (0x0020): [RID#4]
> privileged_krb5_setup failed.
> 1277
> (2025-01-06 13:34:39): [krb5_child[5531]] [main] (0x0020): [RID#4]
> krb5_child failed!
> 1278
> ********************** PREVIOUS MESSAGE WAS TRIGGERED BY THE FOLLOWING
> BACKTRACE:
> 1279
> * (2025-01-06 13:34:39): [krb5_child[5531]] [main] (0x0020): [RID#4]
> privileged_krb5_setup failed.
> 1280
> * (2025-01-06 13:34:39): [krb5_child[5531]] [main] (0x0020): [RID#4]
> krb5_child failed!
>
> Ok, enough for this thread, this is just a bug/build fixing matter now.
>
>
>
> https://salsa.debian.org/ahasenack/sssd/-/jobs/6871800/viewer#L1273
>
> On Mon, Jan 6, 2025 at 10:01 AM Andreas Hasenack
> <andreas.hasenack at canonical.com> wrote:
> >
> > The DEP8 test for kerberos password authentication is failing[1], and
> > looks like it's a legit error:
> >
> > Jan 05 10:23:02 ldap.example.com systemd[1]: Started ssh.service -
> > OpenBSD Secure Shell server.
> > 1698
> > Jan 05 10:23:02 ldap.example.com sshd-session[5325]:
> > pam_unix(sshd:auth): authentication failure; logname= uid=0 euid=0
> > tty=ssh ruser= rhost=::1 user=testuser1
> > 1699
> > Jan 05 10:23:02 ldap.example.com sshd-session[5325]:
> > pam_sss(sshd:auth): authentication failure; logname= uid=0 euid=0
> > tty=ssh ruser= rhost=::1 user=testuser1
> > 1700
> > Jan 05 10:23:02 ldap.example.com sshd-session[5325]:
> > pam_sss(sshd:auth): received for user testuser1: 4 (System error)
> >
> > gather_logs() missed getting sssd specific logs, so I don't know what
> > the error was over there. I'm trying to reproduce this.
> >
> > 1. https://salsa.debian.org/sssd-team/sssd/-/jobs/6866631/viewer#L1697
> >
> > On Sun, Jan 5, 2025 at 10:10 AM Andreas Hasenack
> > <andreas.hasenack at canonical.com> wrote:
> > >
> > > Thanks Timo
> > >
> > > On Sun, Jan 5, 2025 at 7:01 AM Timo Aaltonen <tjaalton at debian.org> wrote:
> > > >
> > > > Andreas Hasenack kirjoitti 31.12.2024 klo 21.36:
> > > > > Hm, what's the salsa workflow? I see salsa/upstream, which looks like
> > > > > needs updating, and then that gets merged into salsa/master and that's
> > > > > where the work then happens, is that it?
> > > >
> > > > Pretty much, although for major new releases the branches usually aren't
> > > > fast-forwardable, so I do
> > > >
> > > > git co upstream
> > > > git reset --hard 2.10.1
> > > > git co -b m
> > > > git merge -s ours 2.9.5
> > > > git merge master
> > > > git branch -M master
> > > >
> > > > that's how at least mesa is handled on the pkg-xorg side, and avoids
> > > > merging unrelated histories that clutter up git log.
> > > >
> > > > I had 2.10.0-beta2 prepared locally, so I've updated that and pushed
> > > > what I have to let you work on it from there. I don't have an
> > > > environment to test on..
> > > >
> > > > Or we'll just shove it to sid as-is.
> > >
> > > There are changes to privileges, and under which user sssd runs:
> > > https://sssd.io/release-notes/sssd-2.10.0.html
> > >
> > > I'll take it for a spin and make further adjustments if needed.