Bug 2854

Using -m shadow does not segfault but always returns 2 = cannot read database.
But /etc/passwd and /etc/shadow are in place and have the correct permissions.

#include <crypt.h>
is missing in checkpass_shadow.c

adding the #include <crypt.h> fixes it for me.

it's possibly a thing with the new glibc.

Hi Thomas,
can you provide more info on:
- distro you are using
- TDE version you are using
- how to replicate the bug, for testing
- login manager settings (sue SAK or not)

I am unable to replicate this bug. kcheckpass seems to work fine.
Please provide info on how to replicate this.

Did you read my comments?

After 7 months, I have moved on to other things and no longer use the system on which I found this bug.

> Did you read my comments?
> After 7 months, I have moved on to other things and no longer use the system on 
> which I found this bug.
Yes, I do. And I remember that you mentioned that on a previous bug a few weeks ago. But forgive me if it didn't come straight to my mind when dealing with all bug reports in bugzilla.....


Since kcheckpass seems to work fine (as well as desktop locking) and we can't reproduce this, I am marking it as "works for me".
If anyone comes along this bug and can provide info on how to reproduce it, please reopen the bug and we will look into it.

Created attachment 3047 [details]
Proposed patch for Slackware non PAM systems

Michele -- long time no see. :-)

Yes, I'm back -- sort of. I am again tinkering with TDE and stumbled across this bug. When I read the comments here I remembered discussing this bug when I was active in the community.

Important to note is this bug never will surface in a PAM-based system, which is why most of you never could reproduce the bug.

The bug appears in Slackware releases previous to Slackware 15.0 (released 2022-02-02) because PAM was not previously supported. Thus the shadow method has to be used to unlock passwords.

I have a variety of Slackware systems and VMs in the house network, including Slackware 14.1, 14.2, and 15.0. The patch resolves the original problem in 14.1 and 14.2 (no PAM) and does not affect 15.0 (PAM).

Please merge the patch.

Hi Darrell,
really long time no see :-)

I have no problem to merge the patch and will do so. Just for my own info, in which way does this fix the issue?

I am also surprised at how one include can solve the problem observed while running, not during build. The only thing I see in the code is to use HAVE_PW_ENCRYPT, which I do not see defined anywhere. Is it possible that this is defined somewhere on Slackware?

Nice to see you Darrell.

Michele,

The fix is a corner case for operating systems not using PAM. Merging the patch fixes the problem with pre-PAM Slackware releases. Since the (overwhelming) number of distros have used PAM for many years, the bug is not going to appear with those distros. I do not know what other non PAM distros might exist -- probably none to very few. Slackware only recently adopted PAM in 15.0. Slackware 14.2 and 14.1 are still supported and those releases do not support PAM. Hence the crash when trying to unlock the screen.

Since the shadow method to decrypt the user's screen lock is not going to be called from within PAM systems, I doubt the patch will break PAM systems.

I hope this helps!

Slavek,

I (still) am not a coder, but I can walk my way around easily enough. 

Short answer:

Seems HAVE_PW_ENCRYPT got lost in the cmake conversion, but the usage might have been forgotten long before then.

Long answer:

I grepped the tdelibs and tdebase code and see what you mean about HAVE_PW_ENCRYPT. In that code snippet I do not know what the difference is between pw_encrypt and crypt methods/functions. In the TDE code the only place the HAVE_PW_ENCRYPT string appears is in kcheckpass/checkpass_shadow.c.

As part of my return to TDE, a while ago I created a Slackware 12.2 (released Dec. 2008) VM with KDE 3.5.10. I have the sources for the KDE packages that were included then. The HAVE_PW_ENCRYPT string appears in the 3.5.10 automake file config.h.in:

/* Define to 1 if you have the `pw_encrypt' function. */
#undef HAVE_PW_ENCRYPT

That raised the question of what is the pw_encrypt function. There is a related comment in the KDE 3.5.10 code -- and the comment remains in the TDE checkpass_shadow.c (line 81).

That comment seems to imply that once upon a time [g]libc did not directly support shadow encryption. Check your system -- there is a crypt man page that mentions [g]libc.

This seems to tie together because /usr/include/crypt.h is installed by the glibc package.

That said, the KDE 3.5.10 checkpass_shadow.c does not include crypt.h and the lock screen bug does not reproduce in my 3.5.10 VM. In Slackware 12.2, glibc 2.7 is installed and that version installed a crypt.h include file. Perhaps shadow support was obtained through some other mechanism in KDE.

One way or another seems HAVE_PW_ENCRYPT got lost in the cmake conversion, but I do not know why the problem does not appear in 3.5.10. I remember this problem from when I was active with TDE. I can't find anything in my original TDE notes. The earliest set of tarballs I still have is R14.0.0. I do not have sources for TDE 3.5.x. I seem to recall raising the topic before this bug report was filed (2018-01-04), or perhaps I was aware and never got around to reporting anything. I cannot find a related Bugzilla report so perhaps the user/developer discussion lists might help. Why the patch is now needed seems to imply something else changed through the years within TDE. But I am not a coder or historian and this little reply has already taken me deep into the proverbial rabbit hole. :-)

I hope this helps!

I have some sources for TDE 3.5.13.2 (from Ubuntu 12.10), if needed.

The patch was merged. Thanks Darrell!