GitLab

accountsservice will try to run commands under the loginuid of the
caller that initiates a command. This gives a better trail in the
audit log of who is doing what.

Many systems now use CONFIG_AUDIT_LOGINUID_IMMUTABLE, though, making
loginuid spoofing not even possible.

Furthermore, some versions of systemd seem to be failing to handle
putting /proc/self/loginuid in the ReadWritePaths list failing
with an error:

  Failed to mount /run/systemd/unit-root/proc/844/loginuid to /run/systemd/unit-root/proc/844/loginuid: Permission denied
  accounts-daemon.service: Failed to set up mount namespacing: /run/systemd/unit-root/proc/844/loginuid: Permission denied
  accounts-daemon.service: Failed at step NAMESPACE spawning /usr/libexec/accounts-daemon: Permission denied

This commit drops all mentions of loginuid to workaround that error.

Closes: #102

accountsservice parses wtmp anytime it changes, so that it has
an accurate accounting of user login frequency. This is important
so that, e.g., the login screen can show the list of users in
the order they use the system the most.

The wtmp file can get very big though and take a long time to parse.

Furthermore, in one scenario where it gets big, a user constantly
logging in and out of the system, it also get written to frequently.
In that case accountsservice basically constantly reparses the big
file, chewing through CPU.

This commit attempts to mitigate that scenario, by more aggressively
rate limiting how often it reparses the file.

Previously it would only parse the file 2 times a seconds at most.
Now it only parses the file once every 10 seconds at most.

Closes: #104

AddUser is a DBus method with a signature so we need to provide all
required arguments, we can't rely on python defaults. This worked
before dbusmock commit f8709a9 because these methods were never really
looked at.

It's a boolean, not a string

Sebastien authored Feb 22, 2022 and Ray Strode committed Feb 23, 2022

Sometime the API users store data in tmp, without the restriction set
settings fail to set the user icon for example.

They were all broken before for the tarball case and I didn't
notice because I was checking the tarball in a subdirectory of
the git repo so it was just exercising the git path.

This commit makes one more attempt at fixing the issue, and
also provides some protection against users that does shallow
clones.

#99

Ray Strode authored Feb 15, 2022 and Ray Strode committed Feb 15, 2022

When generating the version for the project, the first step is
to determine if the source is from a release or a clone from git.

The script does this by looking at the directory name and seeing
if it has a hyphen in it. If so, it assumes it's a tarball.

This is a bad heuristic, since clones from git can be put into
any directory name the cloner wants, including directory names
with hyphens!

This commit fixes that edge case by explicitly looking for a clone
from git first.

#99

Ray Strode authored Feb 15, 2022 and Ray Strode committed Feb 15, 2022

Using the current date means builds aren't reproducible if run at
different times.

This commit changes the version determination logic to look at the
last commit date instead of the current date.

In our environment, the default umask is `0o022` so the `g+w` permission
is missing from the packaged `icons` directory.

Manipulate the umask to match the modes we want.

We can't just use `0` for everything because `makedirs` always uses
`0o777` for parent directories [since Python 3.7][1]. We also want to
keep `/var/lib` at `0o755`.

[1]: https://bugs.python.org/issue19930

Part-Of: !88

In the previous commit I changed NEWS to a stub saying to run git log,
but I just realized telling someone who has potentially just unpacked
a tarball to run git log is silly and wrong.

This commit drops NEWS entirely.

Maybe we can generate it from CI or something down the line.

The NEWS file is an attempt to distill what changes have gone in since
last release from the commits.

But accountsservice is a pretty slow moving project and it doesn't
really provide that much value over reading the commits directly.

This commit drops the file, to make it easier to do releases.

Numbers are arbitrary, and we've never successfully made it to
version 1.0 after like 12 years or something.

Furthermore, accountsservice has a very slow release schedule at present
and some distros hate building from git.

So, I'd like to start generating tarballs more regularly.

Adopting a version number derived from the date will help facilitate
that.

This commit introduces a script to figure out the version number based
on the date and the number of commits since the last release.

The extra admin groups list is a build-time option, but there is no guarantee
the groups are available on the installed system. Currently if an extra admin
group is missing on the system, accountsservice's will fail to create users
because the underlying useradd call will fail.

This commit fixes the issue, by pre-validating the extra admin groups
list.

Positional parameters to merge_file() were never allowed and always
ignored, so just drop it.
See: https://github.com/mesonbuild/meson/issues/9441

Fixes #97

Rafael Fontenelle authored Aug 01, 2021 and Ray Strode committed Oct 12, 2021

Contribution by Henrique Machado Campos

Ray Strode authored Sep 09, 2021 and Ray Strode committed Oct 08, 2021

At the moment, at start up we unconditionally reset permission of all
cache files in /var/lib/AccountsService/users.  If the mode of the files
can't be reset, accountsservice fails to start.

But there's a situation where we should proceed anyway: If the
mode is already correct, and the file is read-only, there is no reason
to refuse to proceed.

This commit changes the code to explicitly validate the permissions of
the file before failing.

Ray Strode authored Sep 08, 2021 and Ray Strode committed Oct 08, 2021

At the moment we do dodgy checks based on uid to decide whether or not
an account is a system account.

For legacy reasons, sometimes normal users have really low UIDs.

This commit reshuffles things, so the cache file "wins" for deciding
whether or not a user is a system user.

Ray Strode authored Aug 04, 2021 and Ray Strode committed Oct 08, 2021

At the moment there's no easy way to set a default session, or
face icon or whatever for all users.  If a user has never logged in
before, we just generate their cache file from hardcoded defaults.

This commit introduces a template system to make it possible for
admins to set up defaults on their own.

Admins can write either
/etc/accountsservice/user-templates/administrator
or
/etc/accountsservice/user-templates/standard

files.  These files follow the same format as

/var/lib/AccountsService/users/username

files, but will support substituting $HOME and $USER to the appropriate
user specific values.

User templates also support an additional group [Template] that
have an additional key EnvironmentFiles that specify a list
of environment files to load (files with KEY=VALUE pairs in them).
Any keys listed in those environment files will also get substituted.

#63

The daemon code manually calls `g_signal_emit_by_name (user, "changed", 0)` every time it changes that users `automatic-login` property.
This emission is redundant because the user code sets up a `notify` handler to emit `changed` it self any time any of its properties are changed.

The variable uid is used only when the loginuid cannot be obtained
or is empty. Change it to get the variable uid when needed

The proxy "xsession" property is exposed as "x-session" to the API, so
don't break the API, but translate the name internally.

Accounts service provides the user's set_user_name() function that
allows to change an user username, but if this happens the user won't
ever be moved by index in the containing hash table, causing the user to
be never deleted when calling delete_user() and it will be always
exposed when listing or fetching it.

In fact we refer to the users only by their usernames but this may
change and in such situation they'd be left stale in the containing
table.

So, add ability to get an user by the UID, and use this function to
check if the user has been renamed during the "changed" callback and if
so, update its hashtable key.

Philip Withnall authored Jun 18, 2020 and Philip Withnall committed Mar 16, 2021

The refcounting of `ActUser` instances was a bit jumbled and unclear,
and seemed to contain several bugs. In particular,
`act_user_manager_get_user_by_id()` was behaving as `(transfer full)`
when it was documented as `(transfer none)`.

Try and tidy the refcounting up, to a certain extent. There may still be
issues left.
Signed-off-by: Philip Withnall <withnall@endlessm.com>

Philip Withnall authored Jun 18, 2020 and Philip Withnall committed Mar 16, 2021

Signed-off-by: Philip Withnall <withnall@endlessm.com>