Re: [Bug 1777860] Re: Sssd doesn't clean up PIDfile after crash
On 06/21/2018 04:39 PM, Robie Basak wrote: > Thank you for taking the time to report this bug and helping to make > Ubuntu better. > > It looks like upstream added a PIDFile entry to the systemd service > definition in 1.16.1, which is included in Bionic and Cosmic. So it's > likely that this bug is fixed there. > > Therefore this bug affects only Xenial and possibly Artful. > >> In our environment, with hundreds of computers running Ubuntu, the > 'solution' brought forth in that discussion, to investigate and handle > the issue manually, is not a serious option. > > Did you know that you can work around the problem by creating an > override file at /etc/systemd/system/sssd.service? > Thanks for pointing that out! I should've thought of it, but I guess my brain stopped once I had fixed it in /lib. 'gards Jurjen > Nevertheless we should fix this in Xenial for the benefit of all other > users who hit this, but now that you know the workaround should stop the > bug affecting you easily enough. > > ** Also affects: sssd (Ubuntu Xenial) >Importance: Undecided >Status: New > > ** Changed in: sssd (Ubuntu) >Status: New => Fix Released > > ** Changed in: sssd (Ubuntu Xenial) >Status: New => Triaged > > ** Changed in: sssd (Ubuntu Xenial) >Importance: Undecided => Medium > > ** Tags added: server-next > -- You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. https://bugs.launchpad.net/bugs/1777860 Title: Sssd doesn't clean up PIDfile after crash To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/sssd/+bug/1777860/+subscriptions -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
[Bug 1777860] [NEW] Sssd doesn't clean up PIDfile after crash
Public bug reported: After having crashed, sssd will not start, because the old PIDfile is still present. The fact that the process does not exist any more does not cause the PIDfile to be cleaned up. This bug is already known, but not fixed, upstream: https://pagure.io/SSSD/sssd/issue/3528 (also contains instructions for reproduction). In our environment, with hundreds of computers running Ubuntu, the 'solution' brought forth in that discussion, to investigate and handle the issue manually, is not a serious option. So I propose that we make systemd handle the PIDfile in case of a crash. With the attached one-line patch applied, systemd will clean up the PIDfile after a crash. That way, sssd doesn't have to make assumptions about namespaces, but the package still handles the issue. Mandatory data: Ubuntu version: Ubuntu 16.04.4 LTS Package version: apt-cache policy $(dpkg -S /lib/systemd/system/sssd.service ) sssd-common: Installed: 1.13.4-1ubuntu1.11 What I expect to happen: After kill -9 $(cat /var/run/sssd.pid) the command systemctl start sssd results in a running sssd. What happens instead: No sssd is running. Only after rm /var/run/sssd.pid systemctl start sssd does it run again. ** Affects: sssd (Ubuntu) Importance: Undecided Status: New ** Patch added: "Add PIDFile setting in sssd.service" https://bugs.launchpad.net/bugs/1777860/+attachment/5154643/+files/sssd_pidfile.patch ** Description changed: After having crashed, sssd will not start, because the old PIDfile is still present. The fact that the process does not exist any more does not cause the PIDfile to be cleaned up. This bug is already known, but not fixed, upstream: https://pagure.io/SSSD/sssd/issue/3528 (also contains instructions for reproduction). In our environment, with hundreds of computers running Ubuntu, the 'solution' brought forth in that discussion, to investigate and handle the issue manually, is not a serious option. So I propose that we make systemd handle the PIDfile in case of a crash. With the attached one-line patch applied, systemd will clean up the PIDfile after a crash. That way, sssd doesn't have to make assumptions about namespaces, but the package still handles the issue. Mandatory data: Ubuntu version: - Ubuntu 16.04.4 LTS + Ubuntu 16.04.4 LTS Package version: - apt-cache policy $(dpkg -S /lib/systemd/system/sssd.service ) -sssd-common: Installed: 1.13.4-1ubuntu1.11 + apt-cache policy $(dpkg -S /lib/systemd/system/sssd.service ) + sssd-common: Installed: 1.13.4-1ubuntu1.11 What I expect to happen: After - kill -9 $(cat /var/run/sssd.pid) + kill -9 $(cat /var/run/sssd.pid) the command - systemctl start sssd results in a running sssd + systemctl start sssd results in a running sssd. What happens instead: No sssd is running. Only after - rm /var/run/sssd.pid - systemctl start sssd results in a running sssd + rm /var/run/sssd.pid + systemctl start sssd results in a running sssd does it run again. ** Description changed: After having crashed, sssd will not start, because the old PIDfile is still present. The fact that the process does not exist any more does not cause the PIDfile to be cleaned up. This bug is already known, but not fixed, upstream: https://pagure.io/SSSD/sssd/issue/3528 (also contains instructions for reproduction). In our environment, with hundreds of computers running Ubuntu, the 'solution' brought forth in that discussion, to investigate and handle the issue manually, is not a serious option. So I propose that we make systemd handle the PIDfile in case of a crash. With the attached one-line patch applied, systemd will clean up the PIDfile after a crash. That way, sssd doesn't have to make assumptions about namespaces, but the package still handles the issue. Mandatory data: Ubuntu version: Ubuntu 16.04.4 LTS Package version: apt-cache policy $(dpkg -S /lib/systemd/system/sssd.service ) sssd-common: Installed: 1.13.4-1ubuntu1.11 What I expect to happen: After kill -9 $(cat /var/run/sssd.pid) the command systemctl start sssd results in a running sssd. What happens instead: No sssd is running. Only after rm /var/run/sssd.pid - systemctl start sssd results in a running sssd + systemctl start sssd does it run again. -- You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. https://bugs.launchpad.net/bugs/1777860 Title: Sssd doesn't clean up PIDfile after crash To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/sssd/+bug/1777860/+subscriptions -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
Re: [Bug 1397898] Re: incorrect PID in initscript
On 12/02/2014 12:21 AM, Matthaus Owens wrote: > Sorry, I should have said pidfile is written to $rundir/agent.pid. > $rundir defaults to $vardir/run if not specified in puppet.conf. > Thank you! Now my config works, and this 'bug' report should never have existed. :) -- You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. https://bugs.launchpad.net/bugs/1397898 Title: incorrect PID in initscript To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/puppet/+bug/1397898/+subscriptions -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
Re: [Bug 1397898] [NEW] incorrect PID in initscript
On 12/01/2014 10:42 PM, Stig Sandbeck Mathisen wrote:
> That's a delightfully evil hack. Will using an upstart job work instead,
> or do you need to keep track of the PID there, as well (something for
> post-start, then)?
Matthaus Owens of Puppet Labs responded that Puppet *does* write its own
PID. This is true for both the newest Puppet version from Puppet Labs
and the version currently in Ubuntu Trusty. So my patch is not needed
after all. It is enough to put the following in /etc/default/puppet
(which is source by the init script):
PIDFILE="/var/lib/puppet/run/agent.pid"
That is assuming that puppet.conf is the default. Alternatively,
according to
https://docs.puppetlabs.com/references/latest/configuration.html#pidfile
it is possible to set the location of the PIDfile to
/var/run/puppet/${NAME}.pid in /etc/puppet/puppet.conf.
--
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bugs/1397898
Title:
incorrect PID in initscript
To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/puppet/+bug/1397898/+subscriptions
--
ubuntu-bugs mailing list
ubuntu-bugs@lists.ubuntu.com
https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
Re: [Bug 1397910] Re: Puppet daemon dies from SIGUSR1 if no certificate
On 12/01/2014 07:31 PM, Robie Basak wrote: > What is it trying to look up? Itself, or something else? I'd expect a > self-lookup to always succeed. It tries to look up the Puppet server, to fetch a certificate from. Maybe it also tries to look up itself. But that would succeed, indeed. > If for some reason it does need to hit the network in the typical case, > then I agree that a timeout may make sense. In this case, I suggest > going to upstream to implement proper retry functionality, rather than > trying to work around it in an init script. Agreed. Doing so. Perhaps better close this bug, then. >> If I write an upstart job, do I upload it to Debian or to PuppetLabs? > > Debian I guess, though they might be interested in hearing upstream's > view on this first. That's why I'm asking there, too. But I do have to try with their newer versions. Thank you for your time! -- You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. https://bugs.launchpad.net/bugs/1397910 Title: Puppet daemon dies from SIGUSR1 if no certificate To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/puppet/+bug/1397910/+subscriptions -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
Re: [Bug 1397898] Re: incorrect PID in initscript
> It should go to Debian in the first instance, assuming that Debian is Ok. Then it'll have to wait until I can confirm that Debian is affected as well. Thanks! -- You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. https://bugs.launchpad.net/bugs/1397898 Title: incorrect PID in initscript To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/puppet/+bug/1397898/+subscriptions -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
Re: [Bug 1397910] Re: Puppet daemon dies from SIGUSR1 if no certificate
On 12/01/2014 06:49 PM, Robie Basak wrote: > Then isn't something else broken that causes puppet to be started before > hostname resolution is available? What is on your system that causes > hostname resolution to not be available? Can we fix that instead? > Perhaps we can. Puppet runs from a SystemV init script, which does require named. But even a running named is no guarantee that resolution succeeds. So still, the Puppet daemon shouldn't give up just because it doesn't immediately succeed, IMHO. That's not robust enough. If I write an upstart job, do I upload it to Debian or to PuppetLabs? -- You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. https://bugs.launchpad.net/bugs/1397910 Title: Puppet daemon dies from SIGUSR1 if no certificate To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/puppet/+bug/1397910/+subscriptions -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
[Bug 1397898] Re: incorrect PID in initscript
Version data: Ubuntu Trusty Puppet 3.4.3-1 0 -- You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. https://bugs.launchpad.net/bugs/1397898 Title: incorrect PID in initscript To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/puppet/+bug/1397898/+subscriptions -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
[Bug 1397910] [NEW] Puppet daemon dies from SIGUSR1 if no certificate
Public bug reported: Abstract: When the Puppet agent daemon is unable to get a certificate, it dies on receiving SIGUSR1. Longer version: Right after boot, the Puppet agent daemon is started. It may be running before hostname resolution is available. If it is, Puppet is unable to receive a certificate. A Puppet daemon that receives SIGUSR1 should try to do a Puppet run immediately. But if it has no certificate, it dies instead, leaving the host unable to receive further configuration until the next reboot. IMHO, Puppet should not die, but retry fetching a certificate. Barring that, an upstart job could restart the daemon when it dies. I could write that upstart job, but I wonder how the maintenance of such distribution-specific config is organized, and whether to push it upstream through Ubuntu or through PuppetLabs. Version data: Ubuntu Trusty Puppet 3.4.3-1 0 ** Affects: puppet (Ubuntu) Importance: Undecided Status: New -- You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. https://bugs.launchpad.net/bugs/1397910 Title: Puppet daemon dies from SIGUSR1 if no certificate To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/puppet/+bug/1397910/+subscriptions -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
[Bug 1397898] [NEW] incorrect PID in initscript
Public bug reported:
Abstract:
Puppet initscript doesn't record the correct PID. WIth this patch, it does.
Longer version:
When the Puppet agent daemon gets started, /etc/init.d/puppet records a PID in
/var/run/puppet/${NAME}.pid, but it is the wrong one. Puppet may fork half a
dozen times before settling on a PID. Start-stop-daemon has no way to keep
track of such behaviour, and I know of no way to make Puppet write its own PID
to a file. So I patched the script.
The patch isn't completely fool proof, but we ran it in production for months,
and it's certainly better than no PID at all.
Is Ubuntu the place to offer such fixes? Or is it better to take them to
Debian, or to PuppetLabs?
** Affects: puppet (Ubuntu)
Importance: Undecided
Status: New
** Patch added: "Patch to make Puppet initscript find the PID of the daemon"
https://bugs.launchpad.net/bugs/1397898/+attachment/4271933/+files/puppet-init.patch
--
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bugs/1397898
Title:
incorrect PID in initscript
To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/puppet/+bug/1397898/+subscriptions
--
ubuntu-bugs mailing list
ubuntu-bugs@lists.ubuntu.com
https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
[Bug 1353502] Re: NFS4 mount fails with AD Kerberos and long hostnames
Please don't bother any more. I offered the patch upstream, and it was committed there. (Plus a line that fixes the memory leak I introduced above.) Regards Jurjen -- You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. https://bugs.launchpad.net/bugs/1353502 Title: NFS4 mount fails with AD Kerberos and long hostnames To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/nfs-utils/+bug/1353502/+subscriptions -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
[Bug 1353502] [NEW] NFS4 mount fails with AD Kerberos and long hostnames
Public bug reported:
Hi,
Version info:
Using Ubuntu 14.04 LTS 'Trusty', and nfs-utils 1.2.8.
Symptoms:
Mounting kerberized NFS4 shares fails when the host is joined to an Active
Directory domain, but not with the conventional name. Non-kerberized mounts
succeed. Hosts joining the domain with the conventional name for their
principal and/or sAMAccountName can also mount.
My Analysis:
When a host joins an Active Directory domain, it is convention to use the upper
case non-fully-qualified domain name followed by a '$' as a principal name. But
Windows cannot handle names longer than 19 characters. So when using longer
hostnames, another string must be used, e.g. the IP number.
NFS looks only for $, and fails if no principal by that name exists.
AD forbids authentication with host/ or nfs/. The manpage of
'msktutil' states that setting the userPrincipalName to host/ should fix
that. But in my case, it doesn't. And in many cases, it is impractical
(requiring elevated privileges on Windows).
Included is a patch of utils/gssd/krb5_util.c that enables the system
administrator to write a stanza in /etc/krb5.conf to override the name
of the principal NFS should look for when authenticating against AD:
[appdefaults]
nfs = {
ad_principal_name = 192.168.5.13$
}
I'm not sure whether to offer this patch here, to Debian, upstream, or all
three.
Also, it makes use of an otherwise rarely used corner of Kerberos: appdefaults.
Regards
Jurjen
** Affects: nfs-utils (Ubuntu)
Importance: Undecided
Status: New
** Patch added: "Make NFS look for configurable AD principal"
https://bugs.launchpad.net/bugs/1353502/+attachment/4171128/+files/krb5_util.patch
--
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bugs/1353502
Title:
NFS4 mount fails with AD Kerberos and long hostnames
To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/nfs-utils/+bug/1353502/+subscriptions
--
ubuntu-bugs mailing list
ubuntu-bugs@lists.ubuntu.com
https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
[Bug 1302638] Re: augeas-tools fails to parse krb5.conf (solution provided)
Err.. s/depends/build-depends/ -- You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. https://bugs.launchpad.net/bugs/1302638 Title: augeas-tools fails to parse krb5.conf (solution provided) To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/augeas/+bug/1302638/+subscriptions -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
[Bug 1302638] Re: augeas-tools fails to parse krb5.conf (solution provided)
I opened a PR on Github as Raphaël requested. One more thing: the Trusty source package depends neither on flex nor on bison. I think it should, but I'm not sure enough to open another bug. -- You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. https://bugs.launchpad.net/bugs/1302638 Title: augeas-tools fails to parse krb5.conf (solution provided) To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/augeas/+bug/1302638/+subscriptions -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
[Bug 1302638] Re: augeas-tools fails to parse krb5.conf (solution provided)
Ok, I cloned the GitHub repository, forked, making changes. As for unit tests, it looks to me like an entire lens is the unit of testing, so I would edit lenses/tests/test_krb5.aug to include some previously unparsed in- and output. Is that what you want me to do? Also, it's not unlikely that I'll need more changes to this particular lens in the near future (weeks to months). Am I right assuming that - it's better to send multiple PRs than to accumulate, and - patches that can pass for a bugfix will get into Trusty even after it is released, whereas ones that seriously change the parse tree won't make it into Trusty even if I were to open the PR tomorrow? -- You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. https://bugs.launchpad.net/bugs/1302638 Title: augeas-tools fails to parse krb5.conf (solution provided) To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/augeas/+bug/1302638/+subscriptions -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
[Bug 1302638] Re: augeas-tools fails to parse krb5.conf (solution provided)
I'm the one who should do the thanking: I'm using your distro. I have not sent the changes upstream. I'm not very familiar with the jargon of parse tree structure. I'd say it obviously causes changes in the structure of the tree: it adds leaves. But I presume the question is meant: "Are there any trees that are parseable by both the unpatched and the patched lens, but which do not give identical trees?" I do not know whether to answer yes or no. The 'shapes' (in terms of number of edges from each node) will be identical, but some nodes will have differently named types, although the renames are quite trivial: of consequence only to the innards of the lens, not to its output. I see that my description of it is already getting longer than the patch itself. I'll happily send the patch upstream if you say that's a better way to go about this. ** Changed in: augeas (Ubuntu) Status: Incomplete => New -- You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. https://bugs.launchpad.net/bugs/1302638 Title: augeas-tools fails to parse krb5.conf (solution provided) To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/augeas/+bug/1302638/+subscriptions -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
[Bug 1302638] [NEW] augeas-tools fails to parse krb5.conf (solution provided)
Public bug reported: In Trusty, augtool doesn't parse the default /etc/krb5.conf There are multiple issues. The lens cannot handle some keywords, it cannot handle heading digits in realm names, and it cannot handle lowercase realms in the [realms] section. After the following patch, it can, and does handle the default krb5.conf. It still doesn't handle all input that is valid to the library, but I don't mind if you ignore that. ** Affects: augeas (Ubuntu) Importance: Undecided Status: New ** Patch added: "Patch taken with diff -u krb5.aug.old /usr/share/augeas/lenses/dist/krb5.aug" https://bugs.launchpad.net/bugs/1302638/+attachment/4065661/+files/krb5.aug.patch.gz ** Patch removed: "Patch taken with diff -u krb5.aug.old /usr/share/augeas/lenses/dist/krb5.aug" https://bugs.launchpad.net/ubuntu/+source/augeas/+bug/1302638/+attachment/4065661/+files/krb5.aug.patch.gz -- You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. https://bugs.launchpad.net/bugs/1302638 Title: augeas-tools fails to parse krb5.conf (solution provided) To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/augeas/+bug/1302638/+subscriptions -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
[Bug 1302638] Re: augeas-tools fails to parse krb5.conf (solution provided)
** Patch added: "output of diff -u krb5.aug.old /usr/share/augeas/lenses/dist/krb5.aug" https://bugs.launchpad.net/ubuntu/+source/augeas/+bug/1302638/+attachment/4065670/+files/krb5.aug.patch -- You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. https://bugs.launchpad.net/bugs/1302638 Title: augeas-tools fails to parse krb5.conf (solution provided) To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/augeas/+bug/1302638/+subscriptions -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
[Bug 1274543] Re: sssd-ad uses wrong key to verify tgt at login time
Additional information: The account ADJoiner is an ordinary user in that it has no servicePrincipalName, whereas hosts do have one. I believe this is a crucial difference, because I can get a ticket for anything that has a servicePrincipalName, but not for anything that doesn't. And indeed, when the first key in the keytab is for another principal that has no servicePrincipalName, the error also occurs. -- You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. https://bugs.launchpad.net/bugs/1274543 Title: sssd-ad uses wrong key to verify tgt at login time To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/sssd/+bug/1274543/+subscriptions -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
[Bug 1274543] [NEW] sssd-ad uses wrong key to verify tgt at login time
Public bug reported:
I try to log in using sssd with AD authentication. It fails.
When I remove the first key from the keytab, logging in succeeds.
Restoring the previous keytab brings the failure back.
Hence, I believe the closing of
https://fedorahosted.org/sssd/ticket/1871#comment:2 to be wrong.
(But I use Trusty, with sssd-*-1.11.3-1, so I'm not sure whether to report here
or at Fedora.)
Additional circumstantial evidence:
The offending first key in the keytab belongs to a principal - let's call it
'ADJoiner' - used solely for the purpose of joining the machine to the AD
domain (which was done using msktutil). The AD admins here say they
deliberately reduced the access rights of ADJoiner. So from Linux perspective,
this principal behaves a bit oddly:
I can kgetcred a ticket for many principals in the same realm, but I cannot
kgetcred a ticket for ADJoiner. I *can* kinit ADJoiner though.
I believe the cause of the problem to be in src/providers/krb5/krb5_child.c in
the loop immediately following the comment:
/* We look for the first entry from our realm or take the last one */
Indeed, if I make that loop skip the first key found (diff below), everything
works as expected, whether the ADJoiner key is in the keytab or not.
This is an ad-hoc fix for my case of course. I think *all* keys from the
keytab should be tried. But sssd obviously intends not to.
*** src/providers/krb5/krb5_child.c.old 2014-01-30 15:48:15.197154787 +0100
--- src/providers/krb5/krb5_child.c 2014-01-30 15:26:02.729103935 +0100
***
*** 703,706
--- 703,707
krb5_ccache validation_ccache = NULL;
krb5_authdata **pac_authdata = NULL;
+ int skip = 0;
memset(&keytab, 0, sizeof(keytab));
***
*** 741,750
if (krb5_realm_compare(kr->ctx, validation_princ, kr->creds->client))
{
! {
DEBUG(SSSDBG_TRACE_INTERNAL,
("Found keytab entry with the realm of the credential.\n"));
realm_entry_found = true;
break;
! }
}
--- 742,757
if (krb5_realm_compare(kr->ctx, validation_princ, kr->creds->client))
{
! if (skip == 0)
! {
! skip++;
! }
! else
! {
DEBUG(SSSDBG_TRACE_INTERNAL,
("Found keytab entry with the realm of the credential.\n"));
realm_entry_found = true;
break;
! }
! }
}
** Affects: sssd (Ubuntu)
Importance: Undecided
Status: New
--
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bugs/1274543
Title:
sssd-ad uses wrong key to verify tgt at login time
To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/sssd/+bug/1274543/+subscriptions
--
ubuntu-bugs mailing list
ubuntu-bugs@lists.ubuntu.com
https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
