Results 1 to 6 of 6

Thread: Plasma 5: kcheckpass can't access password database, screen locker doesn't unlock

  1. #1
    Join Date
    Jan 2009
    Location
    Romania, Bucharest
    Posts
    817

    Default Plasma 5: kcheckpass can't access password database, screen locker doesn't unlock

    I upgraded from openSUSE 13.2 to openSUSE Tumbleweed, and from KDE 4.11.x to KDE Framework 5. I immediately noticed that I could no longer unlock my session, because the screen locker sees my password as invalid even when it's not. With some Google searching and help from IRC, I found the source of the problem and a (supposedly temporary) solution:

    https://bugs.kde.org/show_bug.cgi?id=337470

    To check the issue, type "/usr/lib64/libexec/kcheckpass" and you should get the following message: "Information: Permissions on the password database may be too restrictive. Authentication failure". To temporarily fix it use: "sudo chmod +s /usr/lib64/libexec/kcheckpass"

    I'm reporting this here because although the bug has been discussed since earlier this year, it still exists in the latest version of openSUSE Tumbleweed! Anyone upgrading from 13.2 to Tumbleweed can expect the screen locker to no longer unlock because of this. Apparently it is an issue with pam.d, and it is distribution related.
    openSUSE Tumbleweed x64, KDE Framework 5

  2. #2
    Join Date
    Mar 2008
    Location
    Oz
    Posts
    11,728
    Blog Entries
    2

    Default Re: Plasma 5: kcheckpass can't access password database, screen locker doesn't unlock

    Thanks

    I have Tumbleweed installed for a very long time so I ask this: Does this bug also suddenly manifest itself in Tumbleweed systems that have been operating OK so far.
    Leap 42.3 & 15.1 &KDE
    FYIs from the days of yore

  3. #3
    Join Date
    Jan 2009
    Location
    Romania, Bucharest
    Posts
    817

    Default Re: Plasma 5: kcheckpass can't access password database, screen locker doesn't unlock

    Quote Originally Posted by swerdna View Post
    Thanks

    I have Tumbleweed installed for a very long time so I ask this: Does this bug also suddenly manifest itself in Tumbleweed systems that have been operating OK so far.
    I've ran Tumbleweed for several months on another test machine. I have never seen this problem there, only on my Desktop and Laptop today after the 'zypper dup'. So it's probably something that happens during the course of the distribution upgrade.
    openSUSE Tumbleweed x64, KDE Framework 5

  4. #4

    Default Re: Plasma 5: kcheckpass can't access password database, screen locker doesn't unlock

    Quote Originally Posted by MirceaKitsune View Post
    So it's probably something that happens during the course of the distribution upgrade.
    No. Actually it is something that happened during the course of the initial installation, and the problem is because something does *not* happen during the course of the distribution upgrade...

    This problem occurs, when you use pam_unix2.so as PAM's authentication module.
    Plasma5's kcheckpass doesn't get the necessary permissions then to lookup the password.
    With the default pam_unix.so, everything works fine.

    openSUSE used pam_unix2.so as default years ago, but switched to pam_unix.so as default in 12.3.
    So this problem should not exist on fresh installations, and on upgrades of systems freshly installed with 12.3 or later.
    Existing configs are *not* modified on upgrades though, so if you originally installed an earlier version, and upgraded ever since you run into this problem.

    In KDE4 it worked even with pam_unix2.so because kcheckpass was installed suid root. But openSUSE's security team declined that for the Plasma5 version, causing this problem.

    Workarounds:
    - Set /usr/lib64/libexec/kcheckpass suid root, i.e. run:
    Code:
    sudo chmod +s /usr/lib64/libexec/kcheckpass
    (if it's a 32bit system, it would be /usr/lib/libexec/kcheckpass instead)

    Note that updates will overwrite this change, you should add an entry to /etc/permissions.local.

    Or, better:
    - "fix" your PAM config.
    You likely have some *.rpmnew files in /etc/pam.d/, copy/move them over the actual common-xxx-pc files.
    Or run:
    Code:
    pam-config -d --unix2
    pam-config -a --unix
    And no, this is no "temporary fix", but the proper solution. pam_unix2.so is deprecated since years.


    See also: https://bugzilla.opensuse.org/show_bug.cgi?id=931296

  5. #5
    Join Date
    Jan 2009
    Location
    Romania, Bucharest
    Posts
    817

    Default Re: Plasma 5: kcheckpass can't access password database, screen locker doesn't unlock

    Thanks for the extra info, wolfi323! I already fixed it via 'chmod +s /usr/lib64/libexec/kcheckpass', and now I've ran the pam-config commands too which are hopefully a permanent fix. Hopefully this can be fixed in Tumbleweed and automated... things like this popping up out of nowhere is a great reason why many users stick to Windows and avoid Linux.
    openSUSE Tumbleweed x64, KDE Framework 5

  6. #6

    Default Re: Plasma 5: kcheckpass can't access password database, screen locker doesn't unlock

    Quote Originally Posted by MirceaKitsune View Post
    I already fixed it via 'chmod +s /usr/lib64/libexec/kcheckpass',
    As indicated, this is only temporary and will be changed again if you install updates.
    Unless you add a line to /etc/permissions.local...

    Exactly this was what had been done in the KDE4 packages (to make it work there in the first place), but the security team declined that for Plasma5 unfortunately.

    and now I've ran the pam-config commands too which are hopefully a permanent fix.
    Yes, they are.

    Hopefully this can be fixed in Tumbleweed and automated... things like this popping up out of nowhere is a great reason why many users stick to Windows and avoid Linux.
    It is no problem on a fresh installation, or on upgrades if you did a fresh installation of 12.3 or newer.

    But modifying the PAM config automatically on upgrades (or when Plasma5 is installed) might cause undesired behavior/changes in behavior too, and might annoy some people. After all, this is a *user* (or admin in this case) configuration.

    This one is not easy to fix in the packaging, short of installing kcheckpass as suid root which the security team declined.

Tags for this Thread

Posting Permissions

  • You may not post new threads
  • You may not post replies
  • You may not post attachments
  • You may not edit your posts
  •