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

[Andreas Hasenack]

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.