1. 24 Feb, 2020 2 commits
  2. 18 Feb, 2020 1 commit
  3. 11 Feb, 2020 1 commit
  4. 07 Feb, 2020 1 commit
    • Matthew Leeds's avatar
      Check GDBusMessage for INTERACTIVE_AUTHORIZATION flag · d5847d8d
      Matthew Leeds authored
      Currently we always use the flag
      a subject is authorized for an action, meaning that we cause polkit to
      create an interactive dialog box. However since GLib 2.46, there has
      indicates if the caller is prepared to have the user authenticate (e.g.
      it's a user-facing program not a daemon). So, check for this flag in
      The impetus for this patch is that in the Endles fork of
      gnome-control-center we use the library malcontent, and call
      mct_manager_get_app_filter() even when we don't have permission to
      actually read the user's app filter, since it shouldn't cause a dialog
      without MCT_GET_APP_FILTER_FLAGS_INTERACTIVE being passed to it. However
      because accountsservice doesn't respect
      create an auth dialog anyway (and hits an error but that's a separate
      gnome-shell bug).
      In libaccountsservice, we use code generated by gdbus-codegen to call
      D-Bus methods implemented by the daemon, and that generated code
      unconditionally uses G_DBUS_CALL_FLAGS_NONE, which would mean that users
      of libaccountsservice can't use interactive auth. The solution is to
      bump our GLib requirement to 2.63.5 (2.64 hasn't been released yet) and
      pass --glib-min-required 2.64 to gdbus-codegen, which causes the
      generated code to have two more arguments for each method call: one for
      GDBusCallFlags and one for a timeout value.
      in libaccountsservice, to maintain compatibility. It might make sense to
      add API in the future so that users of the library can specify if they
      want to allow interactive auth.
      This commit also makes us use
      implemented by ConsoleKit, even though presumably no problems are caused
      by the current behavior of using G_DBUS_CALL_FLAGS_NONE. In theory
      ConsoleKit could check for
      in practice I think it's deprecated and inactive), and I think the whole
      of libaccountsservice should assume interactive auth is allowed until we
      have API to distinguish the no-interactive-auth case.
  5. 16 Sep, 2019 1 commit
  6. 13 Sep, 2019 1 commit
  7. 06 Sep, 2019 1 commit
    • Robert Ancell's avatar
      build: Bump minimum version of meson required · 2e9ee995
      Robert Ancell authored
      Meson gives the warning:
      WARNING: Project specifies a minimum meson_version '>= 0.46.0' but uses features which were added in newer versions:
       * 0.50.0: {'install arg in configure_file'}
  8. 04 Sep, 2019 1 commit
  9. 25 Aug, 2019 1 commit
  10. 24 Aug, 2019 1 commit
  11. 13 Aug, 2019 2 commits
  12. 01 Aug, 2019 1 commit
  13. 09 May, 2019 1 commit
    • Ray Strode's avatar
      data: don't send change updates for login-history · 64b11314
      Ray Strode authored
      The login-history property of user objects can be quite large.
      If wtmp is changed frequently, that can lead to memory fragmentation
      in clients.
      Furthermore, most clients never check login-history, so it's
      wasted memory and wasted cpu.
      This commit disables change notification for that property.  If
      a client really needs to get updates, they can manually refresh
      their cache when appropriate.
  14. 07 May, 2019 2 commits
    • Philip Withnall's avatar
      data: Tighten up systemd sandboxing of accounts-daemon.service · 0e712e93
      Philip Withnall authored
      Tighten up the sandboxing of the daemon, paying particular attention to
      file system access. Further work could be done to make the daemon run as
      a non-root user (User=/Group=/DynamicUser=), drop capabilities
      (CapabilityBoundingSet=) and restrict system calls (SystemCallFilter=).
      This is a reasonable starting point, though. It has been tested with
      adding, modifying and deleting users, and reading/writing user extension
      data. Testing was done on a Fedora and a Debian-based system.
      The useradd/userdel/usermod subprocesses require a lot of permissions
      which the accounts-service daemon itself doesn’t. In future, it might
      make sense to run them in a separate privilege-escalated sandbox, and
      further restrict the permissions of the accounts-service daemon itself.
      Signed-off-by: Philip Withnall's avatarPhilip Withnall <withnall@endlessm.com>
    • Philip Withnall's avatar
      build: Expose chosen path_wtmp value as a variable · 152b845b
      Philip Withnall authored
      This will be used in a following commit.
      Signed-off-by: Philip Withnall's avatarPhilip Withnall <withnall@endlessm.com>
  15. 29 Apr, 2019 1 commit
    • Ray Strode's avatar
      daemon: ensure cache files for system users are processed · d8b77951
      Ray Strode authored
      At the moment we skip cache files for system users.  That
      doesn't make much sense; if there's a cache file we should
      be using it.
      This commit changes the code to read cache files, even for
      system users, and so lets root have a non-default session.
      Closes: #65
  16. 23 Apr, 2019 2 commits
  17. 17 Apr, 2019 1 commit
    • João Paulo Rechi Vita's avatar
      daemon: Wait for reload before servicing list_cached_users · e88a50bd
      João Paulo Rechi Vita authored
      When /etc/passwd, /etc/shadow or /etc/group are changed outside of
      AccountsService, the cache reload is delayed by 500 ms so subsequent
      changes to these files are process seen together and AccountsService has
      a consistent view of the data (since after one of these files is changed
      the others may change too).
      If ListCachedUsers is called in this 500 ms window,
      finish_list_cached_users will be executed before reload_users_timeout
      has been dispatched, since its added to the mainloop as an idler and at
      point there is nothing preventing it from being executed. This makes
      finish_list_cached_users only be attached to the mainloop after
      reload_users_timeout has been dispatched.
      This bug was introduced by commit 4e3fad33 when the 500 ms delay was
      Closes: #71
  18. 09 Apr, 2019 1 commit
  19. 08 Apr, 2019 1 commit
  20. 20 Mar, 2019 1 commit
  21. 15 Mar, 2019 1 commit
  22. 12 Mar, 2019 1 commit
  23. 22 Feb, 2019 4 commits
  24. 20 Feb, 2019 1 commit
  25. 12 Feb, 2019 1 commit
  26. 19 Dec, 2018 1 commit
  27. 02 Oct, 2018 1 commit
  28. 01 Oct, 2018 1 commit
  29. 29 Sep, 2018 3 commits
  30. 26 Sep, 2018 2 commits