1. 30 Aug, 2017 1 commit
    • Martin Flöser's avatar
      Don't dissallow open with write flag syscall on NVIDIA · 2136a38d
      Martin Flöser authored
      The latest NVIDIA driver crashes the greeter due to our seccomp enabled
      sandbox being too restrictive. The driver is now opening files for
      writing after our dummy context got created and this causes a crash. In
      order to provide our users a working system again we better disable the
      seccomp rule for NVIDIA users for the time being.
      To detect whether an NVIDIA driver is used I copied the glplatform from
      KWin which is known to work and more reliable than writing new custom
      code even if it's a code copy. For master I'll look into splitting that
      one out from KWin and putting it into a dedicated library so that we can
      link it.
      This of course means that the seccomp based sandbox is now incomplete
      for NVIDIA users. An idea is to add an additional apparmor rule in
      master to enforce the write restrictions in similar way without forcing
      it for /dev.
      BUG: 384005
      Test Plan: I don't have an NVIDIA
      Reviewers: #plasma
      Subscribers: plasma-devel
      Tags: #plasma
      Differential Revision: https://phabricator.kde.org/D7616
  2. 22 Aug, 2017 1 commit
  3. 18 Jul, 2017 1 commit
  4. 27 Jun, 2017 1 commit
  5. 13 Jun, 2017 1 commit
  6. 06 Jun, 2017 1 commit
  7. 04 Jun, 2017 1 commit
    • Fabian Vogt's avatar
      Fixup protocol mismatch between greeter and kcheckpass · 23fa33ce
      Fabian Vogt authored
      The receiver (kcheckpass) reads a string and if it is !nullptr, reads an int:
      	msg = GRecvStr ();
      	if (msg && (GRecvInt() & IsPassword) && !*msg)
      The sender (kscreenlocker_greet) sends a string and if it is not empty,
      sends an int:
      	if (!m_password.isEmpty()) {
      		// IsSecret
      This does not work out for empty strings, as those still have a length of 1,
      resulting in kcheckpass waiting indefinitely for an int that does not get sent.
      Testing for a nullptr on the sender side instead of the string length fixes this.
      Also clean up the code duplication and IsSecret (1)/IsPassword (2) mismatch.
      BUG: 380491
      Test Plan:
      Reproduced the bug without this patch, with this patch it does not
      happen anymore. Authentication still works and fails as expected.
      Reviewers: #plasma
      Subscribers: plasma-devel
      Tags: #plasma
      Differential Revision: https://phabricator.kde.org/D6091
  8. 30 May, 2017 2 commits
  9. 29 May, 2017 1 commit
  10. 25 May, 2017 1 commit
  11. 23 May, 2017 1 commit
  12. 11 May, 2017 1 commit
  13. 27 Apr, 2017 1 commit
  14. 23 Apr, 2017 1 commit
    • Martin Flöser's avatar
      Prevent kcheckpass from becoming an orphan · c5e49e46
      Martin Flöser authored
      With the long running kcheckpass there is the possibility that
      kcheckpass becomes an orphan. Kcheckpass terminates once it gets
      SIGUSR2 sent from the parent process (that is kscreenlocker_greet).
      If kscreenlocker_greet crashes it cannot send SIGUSR2 to kcheckpass and
      thus kcheckpass becomes an orphan. This can easily be seen in the
      killTest autotest which results in many orphaned kcheckpass processes
      after execution.
      This change uses the linux specific PR_SET_PDEATHSIG to send SIGUSR2 to
      kcheckpass when the parent process dies. Thus kcheckpass can get out of
      the waiting and terminate without becoming an orphan.
      In this case it is not a problem to use a linux specific syscall. The
      long running kcheckpass is only used if kscreenlocker is built with
      seccomp support which is also linux specific.
      Test Plan:
      Run killTest and check the number of orphaned kcheckpass.
      Without this change we had 17 orphaned processes, with this change none.
      Reviewers: #plasma
      Subscribers: plasma-devel
      Tags: #plasma
      Differential Revision: https://phabricator.kde.org/D5547
  15. 22 Apr, 2017 2 commits
    • Martin Flöser's avatar
      Fix removal of lock window on unmap · cc3265cf
      Martin Flöser authored
      Unfortunately our tests did not run on build.kde.org and now that they
      run they show breakage.
      The unmap notifiy handler removes windows from the list of lock windows.
      But it used the event window instead of the window. The event window is
      the rootWindow which is of course no lock window. Due to this the
      unmapped lock window never got removed from the list of lock windows
      which could result in the restacking not working as we tried to restack
      to a non-existing window resulting in an xcb error.
      Normally this should go through review, but I'm skipping it as we have
      a failing auto test for the issue and it's really obvious that event
      window is wrong in this case. We are in a branch which compares the
      event window is the rootWindow, so it really, really is just totally
      With the change the test passes again.
    • Martin Flöser's avatar
      Terminate kscreenlocker_greet and don't kill it on unlockRequest · 88b502d3
      Martin Flöser authored
      When the screen should get unlocked the greeter process needs to be
      terminated. This is handled in various places correctly except for the
      logind integration. There kill was used instead of terminate resulting
      in no cleanup. With the new long running kcheckpass this results in
      orphaned kcheckpass processes.
  16. 20 Apr, 2017 1 commit
  17. 19 Apr, 2017 3 commits
    • Martin Flöser's avatar
      Use seccomp for implementing a sandbox for kscreenlocker_greet · 5e3c7b33
      Martin Flöser authored
      This change introduces a new optional dependency on libseccomp.
      Libseccomp allows to forbid syscalls. With that we can constrain the
      user defined dynamically loaded QtQuick code from the look'n'feel
      package and from the wallpaper package. The idea is to protect against
      "malicious" packages the user manually installed.
      With the installed seccomp filter we can ensure that the QtQuick code
      cannot perform the following operations:
      * send password into Internet through forbidding the socket syscall
      * use KIO to send password into Internet through forbidding fork+exec
      * write password into a file through forbidding opening a file in
       write mode or creating a new file
      * send password to another process through forbidding pipe/pipe2
      So far our QtQuick code was already constrained by disallowing network
      access through injecting a QNetworkAccessManager which forbids internet
      access. But this was easy to circumvent through e.g. KIO.
      The seccomp filter cannot protect against a malicious process already
      running on the system. The obvious way to get out of this sandbox is
      DBus. DBus is allowed in the sandbox, thus it is possible for a malicious
      look'n'feel package to communicate with a running malicious application
      through DBus. To protect DBus we need to implement an additional apparmor
      The seccomp filter gets only installed if the seccomp dependency is
      available and kcheckpass is not setuid. This is ensured with a runtime
      check. For kscreenlocker_greet the main change is that when seccomp is
      enabled the delayed kcheckpass authentication method is used.
      Test Plan:
      Manual testing and a new auto test which verifies the
      restricted conditions.
      Reviewers: #plasma
      Subscribers: plasma-devel
      Tags: #plasma
      Differential Revision: https://phabricator.kde.org/D5029
    • Martin Flöser's avatar
      Support for long running kcheckpass supporting multiple authentications · 07d38ba6
      Martin Flöser authored
      So far kcheckpass allowed to try to verify one password. This required
      kscreenlocker_greet to exec for every new entered password. Due to that
      we cannot enable seccomp in kscreenlocker_greet.
      This change prepares for supporting seccomp by making it possible to
      have a long living kcheckpass with multiple authentications. For that
      the interaction is changed:
      * kcheckpass gets started without going into Authenticate directly
      * kcheckpass uses a signalfd for waiting on sigusr1 and sigusr2
      * kcheckpass goes into a loop for authentication
      ** signals parent process through socket that it is ready for auth
      ** waits for signal
      ** on sigusr1 starts to authenticate
      ** on sigusr2 goes out of loop
      ** after authenticate goes into next loop run to continue
      For the authenticator in kscreenlocker_greet the main change is to
      send the signal to kcheckpass when it wants to authenticate.
      In addition the authenticator supports both a delayed and a direct
      mode. In the delayed case kcheckpass gets started directly on startup
      for the long living process. In the direct mode it starts kcheckpass
      when going into authenticate. We need both modes as kcheckpass is not
      supposed to use the long living process when it is setuid root.
      For the moment kscreenlocker_greet by default still uses the direct
      interaction. This will change when seccomp integration is added.
      The test application gained a new command line switch to use either
      direct or delayed authentication.
      Reviewers: #plasma
      Subscribers: plasma-devel
      Tags: #plasma
      Differential Revision: https://phabricator.kde.org/D4997
    • Martin Flöser's avatar
      [greeter] Send the auth result through the server instead return value · d666fe87
      Martin Flöser authored
      Given that we have the protocol and don't use the legacy conv any more
      there is no need to go through exit code mapping. By not using exit code
      we can start reusing one kcheckpass for multiple auth request and turn it
      into a kind of daemon, which is a requirement for enabling seccomp in
      Test Plan: Tested with the new test helper
      Reviewers: #plasma
      Subscribers: plasma-devel
      Tags: #plasma
      Differential Revision: https://phabricator.kde.org/D4806
  18. 27 Mar, 2017 1 commit
    • Martin Flöser's avatar
      Add support for emergency message show on Wayland · 56525935
      Martin Flöser authored
      When playing with the lockscreen I noticed that the emergency show does
      not work on Wayland and one only gets a black screen if the system fails.
      This change adds a property to the QWindow (in ksld), so that KWin can
      read this and now that this is a window to be shown on the lock screen.
      In addition the geometry of the background window gets adjusted correctly
      on Wayland.
      The change needs a small part also in KWin.
      Reviewers: #kwin, #plasma
      Subscribers: plasma-devel
      Tags: #plasma
      Differential Revision: https://phabricator.kde.org/D5157
  19. 20 Mar, 2017 2 commits
  20. 17 Mar, 2017 1 commit
    • Martin Flöser's avatar
      Require PAM by default and provide an option to not require it · 6ef78dc0
      Martin Flöser authored
      The default should be what most distros and most users/devs use.
      On most distros kcheckpass would be broken without PAM. Thus to not
      require it is a severe issue. We have had many bug reports due to
      PAM missing during build and users not able to unlock.
      Slackware still requires a setup without PAM, thus a cmake option
      is added to not require PAM.
      cmake -DPAM_REQUIRED=OFF /path/to/kscreenlocker/src
      to compile kscreenlocker without PAM support.
      CCMAIL: distributions@kde.org
      CCMAIL: kde-distro-packagers@kde.org
      Test Plan: Tested cmake with and without that option
      Reviewers: #plasma
      Subscribers: plasma-devel
      Tags: #plasma
      Differential Revision: https://phabricator.kde.org/D4768
  21. 16 Mar, 2017 3 commits
    • Martin Flöser's avatar
      [ksld] Don't unset greeter connection on destroy unconditionally · 06917c12
      Martin Flöser authored
      If the greeter exits the Wayland connection gets destroyed and a new
      greeter with a new Wayland connection gets created. As the destroying
      of the Wayland connection is async it can happend that the destroy
      signal is emitted after the new connection is created. So far our code
      unconditionally reset the connection on destroy which resulted in KWin
      not being able to recognize the new greeter and only presenting a black
      screen. After unlock with loginctl unlock-session the session shows a
      dead greater window. Which can be explained by the connection never
      getting destroyed.
      This change verifies that the greeter connection is actually the one
      which is currently in use. If the greeter dies the new greeter is shown
      properly in the Wayland session and no dead greeter is shown after
      BUG: 377152
      Test Plan: killed kscreenlocker_greet 6 times, always properly restarted
      Reviewers: #plasma
      Subscribers: plasma-devel
      Tags: #plasma
      Differential Revision: https://phabricator.kde.org/D5008
    • Martin Flöser's avatar
      [kcheckpass] Drop all outdated/obsoleted checkpass variants · 4cf34fea
      Martin Flöser authored
      This was discussed on the distro mailing list. All checkpass variants
      which are no longer used are removed. What remains are:
       * etcshadow (used by Slackware)
       * pam (used by everybody which is not Slackware, including BSDs)
      Test Plan: Pam path compiles
      Reviewers: #plasma
      Subscribers: plasma-devel
      Tags: #plasma
      Differential Revision: https://phabricator.kde.org/D5005
    • Script Kiddy's avatar
      SVN_SILENT made messages (.desktop file) - always resolve ours · 3c32efbb
      Script Kiddy authored
      In case of conflict in i18n, keep the version of the branch "ours"
      To resolve a particular conflict, "git checkout --ours path/to/file.desktop"
  22. 08 Mar, 2017 3 commits
  23. 02 Mar, 2017 5 commits
  24. 01 Mar, 2017 3 commits
    • Fabian Vogt's avatar
      Merge branch 'Plasma/5.9' · 0b200393
      Fabian Vogt authored
    • Fabian Vogt's avatar
      Merge branch 'Plasma/5.8' into Plasma/5.9 · 195a8b4c
      Fabian Vogt authored
    • Fabian Vogt's avatar
      Implement manual focus on click · f8043de1
      Fabian Vogt authored
      Currently only the first created screenlock window gets focus.
      On clicks, no focus events are sent, which makes it impossible to input
      passwords. This patch now makes it possible to focus to a different
      screenlock window (on a different monitor, for example) using a mouse
      button press.
      This should also fix newly created screenlock windows stealing the focus
      of already displayed ones as only the first window gains automatic focus.
      BUG: 348789
      BUG: 374289
      Test Plan:
      Locked the screen, now I can use the password input on the secondary screen
      as well.
      Reviewers: #plasma, graesslin, broulik
      Reviewed By: #plasma, graesslin
      Subscribers: hein, plasma-devel
      Tags: #plasma
      Differential Revision: https://phabricator.kde.org/D4821
  25. 28 Feb, 2017 1 commit