accountsservice issueshttps://gitlab.freedesktop.org/accountsservice/accountsservice/-/issues2024-03-03T18:48:42Zhttps://gitlab.freedesktop.org/accountsservice/accountsservice/-/issues/121Leak shadow user from previous scan, if current not present in shadow.2024-03-03T18:48:42ZAnton PalgunovLeak shadow user from previous scan, if current not present in shadow.TL;DR need to reset the state of *spent to NULL if the user is not found in /etc/shadow (shadow_entry_buffers == NULL) https://gitlab.freedesktop.org/accountsservice/accountsservice/-/blob/main/src/daemon.c?ref_type=heads#L326
In situa...TL;DR need to reset the state of *spent to NULL if the user is not found in /etc/shadow (shadow_entry_buffers == NULL) https://gitlab.freedesktop.org/accountsservice/accountsservice/-/blob/main/src/daemon.c?ref_type=heads#L326
In situations when we have the shadow file, but a distro doesn't use that in real, possible situations when we have a user in passwd, but nothing in shadow.
In that cases![image](/uploads/6eab0a602e0830b80ec94b289f6a0899/image.png) we reach locked in the weird stack, correct user and incorrect previous success read from shadow.
A few more screens to investigate step by step before the screenshot above
![image](/uploads/052266362cc73f4ddc95be2533b55aaf/image.png)
![image](/uploads/0a855f9b448f2c7dd6180e498c1c02f4/image.png)
![image](/uploads/cb2c4deed5f7f6ca8c6f6bc6f791dc61/image.png)
![image](/uploads/92bed688c9837bc3fcffaaa2b23c82bb/image.png)
Possible is closing #10 as well, because I try to find the issue, but a bit more complex, also affect many cases which aware locked state of user. AutoLogin, User in list, Locked user in settings.https://gitlab.freedesktop.org/accountsservice/accountsservice/-/issues/124Segfault in `daemon_local_set_automatic_login` when trying to enable automati...2024-02-28T00:06:45ZMohammed AnasSegfault in `daemon_local_set_automatic_login` when trying to enable automatic login if no DM is detectedI'm using GNOME on Chimera Linux, and trying to enable automatic login from the Settings app causes `accountsservice` 23.13.9 to segfault. Here's the back trace:
```
* thread #1, name = 'accounts-daemon', stop reason = signal SIGSEGV: a...I'm using GNOME on Chimera Linux, and trying to enable automatic login from the Settings app causes `accountsservice` 23.13.9 to segfault. Here's the back trace:
```
* thread #1, name = 'accounts-daemon', stop reason = signal SIGSEGV: address not mapped to object (fault address: 0x8)
* frame #0: 0x000055555556fdad accounts-daemon`user_change_automatic_login_authorized_cb(daemon=0x00007fffee603db0, user=0x00007fffee100b70, context=0x00007fffeec05f20, data=0x0000000000000001) at user.c:2662:100
frame #1: 0x000055555556959b accounts-daemon`check_auth_cb(authority=<unavailable>, res=<unavailable>, data=0x00007fffef706210) at daemon.c:1681:17
frame #2: 0x00007fffef42cecf libgio-2.0.so.0`g_simple_async_result_complete + 191
frame #3: 0x00007ffff7f72aea libpolkit-gobject-1.so.0`___lldb_unnamed_symbol549 + 378
frame #4: 0x00007fffef4470c3 libgio-2.0.so.0`g_task_return_now.llvm.12815632267297636896 + 35
frame #5: 0x00007fffef445b71 libgio-2.0.so.0`g_task_return.llvm.12815632267297636896 + 289
frame #6: 0x00007fffef4bb2d7 libgio-2.0.so.0`reply_cb + 119
frame #7: 0x00007fffef4470c3 libgio-2.0.so.0`g_task_return_now.llvm.12815632267297636896 + 35
frame #8: 0x00007fffef445b71 libgio-2.0.so.0`g_task_return.llvm.12815632267297636896 + 289
frame #9: 0x00007fffef4ad48d libgio-2.0.so.0`g_dbus_connection_call_done + 317
frame #10: 0x00007fffef447113 libgio-2.0.so.0`complete_in_idle_cb.llvm.12815632267297636896 + 35
frame #11: 0x00007fffef2827b6 libglib-2.0.so.0`g_main_context_dispatch_unlocked + 406
frame #12: 0x00007fffef282d72 libglib-2.0.so.0`g_main_context_iterate_unlocked + 706
frame #13: 0x00007fffef2833cd libglib-2.0.so.0`g_main_loop_run + 413
frame #14: 0x000055555556c6f8 accounts-daemon`main(argc=1, argv=0x00007fffffffecd8) at main.c:283:9
```
The segfault occurs here (when dereferencing `error`, initialized to `NULL`):
```
frame #0: 0x000055555556fdad accounts-daemon`user_change_automatic_login_authorized_cb(daemon=0x00007fffee603db0, user=0x00007fffee100b70, cont
ext=0x00007fffeec05f20, data=0x0000000000000001) at user.c:2662:100
2659 }
2660
2661 if (!daemon_local_set_automatic_login (daemon, user, enabled, &error)) {
-> 2662 throw_error (context, ERROR_FAILED, "failed to change automatic login: %s", error->message);
2663 return;
2664 }
2665
```
I briefly looked into the code, and the only place where `daemon_local_set_automatic_login` returns `FALSE` and therefore causes the `if` statement body to execute is in lines 1907 to 1909 in `src/daemon.c`:
```
if (!save_autologin (daemon, user_get_user_name (user), enabled, error)) {
return FALSE;
}
```
So I went and checked `save_autologin`, and indeed, at the end of the function, `FALSE` is returned without modifying `error`.
Now, I'm using GDM, so I wasn't quite sure why `get_current_system_dm_type` (called in `save_autologin`) fails to detect that I'm using GDM. It didn't take me long to realize that it does that by checking what file the `/etc/systemd/system/display-manager.service` symlink points to; however, Chimera Linux doesn't use systemd (it uses dinit as its service manager and init). I'm not quite sure about the right way to adapt `get_current_system_dm_type` to Chimera Linux, I'll check how later (I might also open a separate ticket for this).https://gitlab.freedesktop.org/accountsservice/accountsservice/-/issues/117User templates only expand variables with braces2023-09-17T13:47:48Zjonathan-conderUser templates only expand variables with bracesRelates to https://gitlab.freedesktop.org/accountsservice/accountsservice/-/issues/63
There's a bug in `expand_template_variables` where the length passed to `g_strndup` is off by 1 when `brackets == FALSE`. For example `$HOME` is evalu...Relates to https://gitlab.freedesktop.org/accountsservice/accountsservice/-/issues/63
There's a bug in `expand_template_variables` where the length passed to `g_strndup` is off by 1 when `brackets == FALSE`. For example `$HOME` is evaluated as `HOM`.
Fix incoming.https://gitlab.freedesktop.org/accountsservice/accountsservice/-/issues/63Support templated user properties (including extension properties)2023-09-17T10:02:08ZPhilip WithnallSupport templated user properties (including extension properties)It would be useful if accountsservice supported a template to populate the properties of a user when a new one is created (using the accountsservice D-Bus interface; this wouldn’t work if `useradd` was run directly by an admin).
For exa...It would be useful if accountsservice supported a template to populate the properties of a user when a new one is created (using the accountsservice D-Bus interface; this wouldn’t work if `useradd` was run directly by an admin).
For example, in Endless OS we have a vendor extension which adds parental controls to user accounts, storing (roughly) a whitelist of apps which that user is allowed to run. We would like to be able to provide a default value for that whitelist which differs based on the account type — empty for administrator accounts, and some deployment-specific whitelist for standard accounts. We can’t change the default value in the vendor extension D-Bus introspection XML file, because that’s stored in the OSTree image and hence can’t vary between deployments (for $ostree_reasons).
Strawman proposal:
* Add a new template file hierarchy, `{/etc,/run,/usr/local/share,/usr/share}/AccountsService/user-templates/{standard,administrator}`, where the `standard` or `administrator` files are key files containing default values.
* The groups and keys are the same as used in the existing `/var/lib/AccountsService/users/${username}` files, and are used to pre-populate those exactly.
* A `standard` template in `/etc/AccountsService/user-templates` overrides one in `/usr/share/AccountsService/user-templates`, etc., following the standard from `man systemd.unit`.
* If the `AccountType` enum grows any more values in future, they would get their own template files.
How does that sound? I’m open to other suggestions to achieve the same goal.https://gitlab.freedesktop.org/accountsservice/accountsservice/-/issues/92Cannot get Git URL to clone repository, "Clone" button on GitLab doesn't work2023-08-20T14:27:57ZAlexander PotashevCannot get Git URL to clone repository, "Clone" button on GitLab doesn't workCannot get Git URL to clone repository, "Clone" button on GitLab doesn't work.
What is the URL for git-clone?Cannot get Git URL to clone repository, "Clone" button on GitLab doesn't work.
What is the URL for git-clone?https://gitlab.freedesktop.org/accountsservice/accountsservice/-/issues/113Invalid read valgrind errors leading to client segfault2023-07-02T16:38:12ZSebastienInvalid read valgrind errors leading to client segfaultIn Ubuntu Lunar we started receiving reports of ayatana-indicator-messages segfaulting, which seems to be triggered at logout for most users (but then the reporting utility prompt them at next login).
The package itself and accountsserv...In Ubuntu Lunar we started receiving reports of ayatana-indicator-messages segfaulting, which seems to be triggered at logout for most users (but then the reporting utility prompt them at next login).
The package itself and accountsservice didn't change so maybe changes in the stack are making the problem visible?
Valgrind shows invalid read error, log from the current git master (d603f80c) doing those steps
```
$ valgrind /usr/libexec/ayatana-indicator-messages/ayatana-indicator-messages-service
$ sudo kill -9 `pidof accounts-daemon`
$ gnome-control-center user-accounts
```
the g-c-c call is having for effect to respawn the service, the error are then displayed
```
==50297== Invalid read of size 8
==50297== at 0x4C0B26A: UnknownInlinedFun (act-user-manager.c:1824)
==50297== by 0x4C0B26A: on_user_manager_maybe_ready_for_request (act-user-manager.c:1814)
==50297== by 0x4A6100F: g_closure_invoke (gclosure.c:832)
==50297== by 0x4A8E3D5: signal_emit_unlocked_R.isra.0 (gsignal.c:3802)
==50297== by 0x4A7E699: g_signal_emit_valist (gsignal.c:3555)
==50297== by 0x4A7E922: g_signal_emit (gsignal.c:3612)
==50297== by 0x4A6BDC3: g_object_dispatch_properties_changed.lto_priv.0 (gobject.c:1428)
==50297== by 0x4A7209E: UnknownInlinedFun (gobject.c:1552)
==50297== by 0x4A7209E: g_object_notify (gobject.c:1602)
==50297== by 0x4C05A34: UnknownInlinedFun (act-user-manager.c:1321)
==50297== by 0x4C05A34: on_name_owner_changed (act-user-manager.c:2525)
==50297== by 0x4A6100F: g_closure_invoke (gclosure.c:832)
==50297== by 0x4A8E3D5: signal_emit_unlocked_R.isra.0 (gsignal.c:3802)
==50297== by 0x4A7E699: g_signal_emit_valist (gsignal.c:3555)
==50297== by 0x4A7E922: g_signal_emit (gsignal.c:3612)
==50297== Address 0x5800e68 is 56 bytes inside a block of size 64 free'd
==50297== at 0x484620F: free (in /usr/libexec/valgrind/vgpreload_memcheck-amd64-linux.so)
==50297== by 0x4C0405F: on_user_destroyed (act-user-manager.c:733)
==50297== by 0x4A6A4E6: weak_refs_notify (gobject.c:3286)
==50297== by 0x4AE84FB: g_data_set_internal (gdataset.c:410)
==50297== by 0x4A6BE14: g_object_real_dispose.lto_priv.0 (gobject.c:1364)
==50297== by 0x4A6ED9F: g_object_unref (gobject.c:3891)
==50297== by 0x4A6100F: g_closure_invoke (gclosure.c:832)
==50297== by 0x4A8E3D5: signal_emit_unlocked_R.isra.0 (gsignal.c:3802)
==50297== by 0x4A7E699: g_signal_emit_valist (gsignal.c:3555)
==50297== by 0x4A7E922: g_signal_emit (gsignal.c:3612)
==50297== by 0x4A6BDC3: g_object_dispatch_properties_changed.lto_priv.0 (gobject.c:1428)
==50297== by 0x4A7209E: UnknownInlinedFun (gobject.c:1552)
==50297== by 0x4A7209E: g_object_notify (gobject.c:1602)
==50297== Block was alloc'd at
==50297== at 0x4843828: malloc (in /usr/libexec/valgrind/vgpreload_memcheck-amd64-linux.so)
==50297== by 0x4B0C948: g_malloc (gmem.c:130)
==50297== by 0x4C0B444: UnknownInlinedFun (act-user-manager.c:1888)
==50297== by 0x4C0B444: act_user_manager_get_user (act-user-manager.c:1994)
==50297== by 0x1134CD: on_user_manager_loaded (im-accounts-service.c:149)
==50297== by 0x4A6100F: g_closure_invoke (gclosure.c:832)
==50297== by 0x4A8E3D5: signal_emit_unlocked_R.isra.0 (gsignal.c:3802)
==50297== by 0x4A7E699: g_signal_emit_valist (gsignal.c:3555)
==50297== by 0x4A7E922: g_signal_emit (gsignal.c:3612)
==50297== by 0x4A6BDC3: g_object_dispatch_properties_changed.lto_priv.0 (gobject.c:1428)
==50297== by 0x4A7209E: UnknownInlinedFun (gobject.c:1552)
==50297== by 0x4A7209E: g_object_notify (gobject.c:1602)
==50297== by 0x4C05A34: UnknownInlinedFun (act-user-manager.c:1321)
==50297== by 0x4C05A34: on_name_owner_changed (act-user-manager.c:2525)
==50297== by 0x4A6100F: g_closure_invoke (gclosure.c:832)
==50297==
==50297== Invalid read of size 1
==50297== at 0x4849CA6: strlen (in /usr/libexec/valgrind/vgpreload_memcheck-amd64-linux.so)
==50297== by 0x4C86317: __printf_buffer (vfprintf-process-arg.c:435)
==50297== by 0x4CA85F3: __vasprintf_internal (vasprintf.c:102)
==50297== by 0x4B5D8C1: UnknownInlinedFun (stdio2.h:169)
==50297== by 0x4B5D8C1: g_vasprintf (gprintf.c:340)
==50297== by 0x4B2ABE0: g_strdup_vprintf (gstrfuncs.c:553)
==50297== by 0x4B0C2F6: UnknownInlinedFun (gmessages.c:3363)
==50297== by 0x4B0C2F6: g_logv (gmessages.c:1318)
==50297== by 0x4B0C7A2: g_log (gmessages.c:1460)
==50297== by 0x4C0B279: UnknownInlinedFun (act-user-manager.c:1824)
==50297== by 0x4C0B279: on_user_manager_maybe_ready_for_request (act-user-manager.c:1814)
==50297== by 0x4A6100F: g_closure_invoke (gclosure.c:832)
==50297== by 0x4A8E3D5: signal_emit_unlocked_R.isra.0 (gsignal.c:3802)
==50297== by 0x4A7E699: g_signal_emit_valist (gsignal.c:3555)
==50297== by 0x4A7E922: g_signal_emit (gsignal.c:3612)
==50297== Address 0x5800f00 is 0 bytes inside a block of size 14 free'd
==50297== at 0x484620F: free (in /usr/libexec/valgrind/vgpreload_memcheck-amd64-linux.so)
==50297== by 0x4C03F90: free_fetch_user_request (act-user-manager.c:1780)
==50297== by 0x4C0405F: on_user_destroyed (act-user-manager.c:733)
==50297== by 0x4A6A4E6: weak_refs_notify (gobject.c:3286)
==50297== by 0x4AE84FB: g_data_set_internal (gdataset.c:410)
==50297== by 0x4A6BE14: g_object_real_dispose.lto_priv.0 (gobject.c:1364)
==50297== by 0x4A6ED9F: g_object_unref (gobject.c:3891)
==50297== by 0x4A6100F: g_closure_invoke (gclosure.c:832)
==50297== by 0x4A8E3D5: signal_emit_unlocked_R.isra.0 (gsignal.c:3802)
==50297== by 0x4A7E699: g_signal_emit_valist (gsignal.c:3555)
==50297== by 0x4A7E922: g_signal_emit (gsignal.c:3612)
==50297== by 0x4A6BDC3: g_object_dispatch_properties_changed.lto_priv.0 (gobject.c:1428)
==50297== Block was alloc'd at
==50297== at 0x4843828: malloc (in /usr/libexec/valgrind/vgpreload_memcheck-amd64-linux.so)
==50297== by 0x4CA8677: __vasprintf_internal (vasprintf.c:116)
==50297== by 0x4B5D8C1: UnknownInlinedFun (stdio2.h:169)
==50297== by 0x4B5D8C1: g_vasprintf (gprintf.c:340)
==50297== by 0x4B2ABE0: g_strdup_vprintf (gstrfuncs.c:553)
==50297== by 0x4B2AC9C: g_strdup_printf (gstrfuncs.c:583)
==50297== by 0x4C0B49A: UnknownInlinedFun (act-user-manager.c:1895)
==50297== by 0x4C0B49A: act_user_manager_get_user (act-user-manager.c:1994)
==50297== by 0x1134CD: on_user_manager_loaded (im-accounts-service.c:149)
==50297== by 0x4A6100F: g_closure_invoke (gclosure.c:832)
==50297== by 0x4A8E3D5: signal_emit_unlocked_R.isra.0 (gsignal.c:3802)
==50297== by 0x4A7E699: g_signal_emit_valist (gsignal.c:3555)
==50297== by 0x4A7E922: g_signal_emit (gsignal.c:3612)
==50297== by 0x4A6BDC3: g_object_dispatch_properties_changed.lto_priv.0 (gobject.c:1428)
==50297== Invalid read of size 2
==50297== at 0x484DAC0: memmove (in /usr/libexec/valgrind/vgpreload_memcheck-amd64-linux.so)
==50297== by 0x4C7CB67: __printf_buffer_write (Xprintf_buffer_write.c:39)
==50297== by 0x4C84CD4: __printf_buffer (vfprintf-process-arg.c:501)
==50297== by 0x4CA85F3: __vasprintf_internal (vasprintf.c:102)
==50297== by 0x4B5D8C1: UnknownInlinedFun (stdio2.h:169)
==50297== by 0x4B5D8C1: g_vasprintf (gprintf.c:340)
==50297== by 0x4B2ABE0: g_strdup_vprintf (gstrfuncs.c:553)
==50297== by 0x4B0C2F6: UnknownInlinedFun (gmessages.c:3363)
==50297== by 0x4B0C2F6: g_logv (gmessages.c:1318)
==50297== by 0x4B0C7A2: g_log (gmessages.c:1460)
==50297== by 0x4C0B279: UnknownInlinedFun (act-user-manager.c:1824)
==50297== by 0x4C0B279: on_user_manager_maybe_ready_for_request (act-user-manager.c:1814)
==50297== by 0x4A6100F: g_closure_invoke (gclosure.c:832)
==50297== by 0x4A8E3D5: signal_emit_unlocked_R.isra.0 (gsignal.c:3802)
==50297== by 0x4A7E699: g_signal_emit_valist (gsignal.c:3555)
==50297== Address 0x5800f08 is 8 bytes inside a block of size 14 free'd
==50297== at 0x484620F: free (in /usr/libexec/valgrind/vgpreload_memcheck-amd64-linux.so)
==50297== by 0x4C03F90: free_fetch_user_request (act-user-manager.c:1780)
==50297== by 0x4C0405F: on_user_destroyed (act-user-manager.c:733)
==50297== by 0x4A6A4E6: weak_refs_notify (gobject.c:3286)
==50297== by 0x4AE84FB: g_data_set_internal (gdataset.c:410)
==50297== by 0x4A6BE14: g_object_real_dispose.lto_priv.0 (gobject.c:1364)
==50297== by 0x4A6ED9F: g_object_unref (gobject.c:3891)
==50297== by 0x4A6100F: g_closure_invoke (gclosure.c:832)
==50297== by 0x4A8E3D5: signal_emit_unlocked_R.isra.0 (gsignal.c:3802)
==50297== by 0x4A7E699: g_signal_emit_valist (gsignal.c:3555)
==50297== by 0x4A7E922: g_signal_emit (gsignal.c:3612)
==50297== by 0x4A6BDC3: g_object_dispatch_properties_changed.lto_priv.0 (gobject.c:1428)
==50297== Block was alloc'd at
==50297== at 0x4843828: malloc (in /usr/libexec/valgrind/vgpreload_memcheck-amd64-linux.so)
==50297== by 0x4CA8677: __vasprintf_internal (vasprintf.c:116)
==50297== by 0x4B5D8C1: UnknownInlinedFun (stdio2.h:169)
==50297== by 0x4B5D8C1: g_vasprintf (gprintf.c:340)
==50297== by 0x4B2ABE0: g_strdup_vprintf (gstrfuncs.c:553)
==50297== by 0x4B2AC9C: g_strdup_printf (gstrfuncs.c:583)
==50297== by 0x4C0B49A: UnknownInlinedFun (act-user-manager.c:1895)
==50297== by 0x4C0B49A: act_user_manager_get_user (act-user-manager.c:1994)
==50297== by 0x1134CD: on_user_manager_loaded (im-accounts-service.c:149)
==50297== by 0x4A6100F: g_closure_invoke (gclosure.c:832)
==50297== by 0x4A8E3D5: signal_emit_unlocked_R.isra.0 (gsignal.c:3802)
==50297== by 0x4A7E699: g_signal_emit_valist (gsignal.c:3555)
==50297== by 0x4A7E922: g_signal_emit (gsignal.c:3612)
==50297== by 0x4A6BDC3: g_object_dispatch_properties_changed.lto_priv.0 (gobject.c:1428)
```https://gitlab.freedesktop.org/accountsservice/accountsservice/-/issues/112meson finds `dbusmock` python module even if not installed on the system2023-04-30T12:04:57ZPierre Labastiemeson finds `dbusmock` python module even if not installed on the systemOn a system without dbusmock installed, the exit code is 0 when running `run_command(python3, '-c', 'import @0@'.format(module), check: false)` (in `tests/meson.build`) for module = 'dbusmock'. The reason is that the directory `tests` co...On a system without dbusmock installed, the exit code is 0 when running `run_command(python3, '-c', 'import @0@'.format(module), check: false)` (in `tests/meson.build`) for module = 'dbusmock'. The reason is that the directory `tests` contains a subdirectory `dbusmock`, which is enough to allow the import to succeed (sys.path contains the current directory).
Meson then fails later when running unittest_inspector.
I guess it would be enough to change the subdirectory name to something else, but I am not sure whether some paths would have to be changed or not.https://gitlab.freedesktop.org/accountsservice/accountsservice/-/issues/41Customize PATH_GDM_CUSTOM via the configure script2023-04-19T17:26:23ZBugzilla Migration UserCustomize PATH_GDM_CUSTOM via the configure script## Submitted by Alessio Treglia
Assigned to **Matthias Clasen `@mclasen`**
**[Link to original bug (#49993)](https://bugs.freedesktop.org/show_bug.cgi?id=49993)**
## Description
Hi,
on Debian and Ubuntu we apply minimalistic dist...## Submitted by Alessio Treglia
Assigned to **Matthias Clasen `@mclasen`**
**[Link to original bug (#49993)](https://bugs.freedesktop.org/show_bug.cgi?id=49993)**
## Description
Hi,
on Debian and Ubuntu we apply minimalistic distro-specific patches to customize PATH_GDM_CUSTOM's value defined in src/daemon.c.
It would be good to have a configure --flag to set a custom value at build time.
Thanks for considering.https://gitlab.freedesktop.org/accountsservice/accountsservice/-/issues/114Valgrind invalid read in indicator messages on logout2023-04-18T23:44:18ZSebastienValgrind invalid read in indicator messages on logoutSimilar to !113 but our accountsservice package include that fix so probably another similar issue
```
==56020== Invalid read of size 8
==56020== at 0x4A70D41: g_type_check_instance (gtype.c:4270)
==56020== by 0x4A63567: g_signal_...Similar to !113 but our accountsservice package include that fix so probably another similar issue
```
==56020== Invalid read of size 8
==56020== at 0x4A70D41: g_type_check_instance (gtype.c:4270)
==56020== by 0x4A63567: g_signal_handlers_disconnect_matched (gsignal.c:3067)
==56020== by 0x4BEF9A7: act_user_manager_finalize (act-user-manager.c:2639)
==56020== by 0x4A59E4B: g_object_unref (gobject.c:3938)
==56020== by 0x112D3A: im_accounts_service_dispose (im-accounts-service.c:80)
==56020== by 0x4A59D9F: g_object_unref (gobject.c:3891)
==56020== by 0x111E52: im_application_list_dispose (im-application-list.c:567)
==56020== by 0x4A59D9F: g_object_unref (gobject.c:3891)
==56020== by 0x11143D: main (messages-service.c:290)
==56020== Address 0x56dc930 is 0 bytes inside a block of size 64 free'd
==56020== at 0x484620F: free (in /usr/libexec/valgrind/vgpreload_memcheck-amd64-linux.so)
==56020== by 0x4A6F66B: g_type_free_instance (gtype.c:2062)
==56020== by 0x4A4C00F: g_closure_invoke (gclosure.c:832)
==56020== by 0x4A793D5: signal_emit_unlocked_R.isra.0 (gsignal.c:3802)
==56020== by 0x4A69699: g_signal_emit_valist (gsignal.c:3555)
==56020== by 0x4A69922: g_signal_emit (gsignal.c:3612)
==56020== by 0x4A56DC3: g_object_dispatch_properties_changed.lto_priv.0 (gobject.c:1428)
==56020== by 0x4A5D09E: UnknownInlinedFun (gobject.c:1552)
==56020== by 0x4A5D09E: g_object_notify (gobject.c:1602)
==56020== by 0x4BF85DD: load_seat_incrementally (act-user-manager.c:2271)
==56020== by 0x4AF336E: UnknownInlinedFun (gmain.c:3460)
==56020== by 0x4AF336E: g_main_context_dispatch (gmain.c:4200)
==56020== by 0x4B4E177: g_main_context_iterate.constprop.0 (gmain.c:4276)
==56020== by 0x4AF2BDE: g_main_loop_run (gmain.c:4479)
==56020== Block was alloc'd at
==56020== at 0x4848A13: calloc (in /usr/libexec/valgrind/vgpreload_memcheck-amd64-linux.so)
==56020== by 0x4AF8550: g_malloc0 (gmem.c:163)
==56020== by 0x4A74B7C: g_type_create_instance (gtype.c:1965)
==56020== by 0x4A5C20F: g_object_new_internal (gobject.c:2246)
==56020== by 0x4A5D7B7: g_object_new_with_properties (gobject.c:2409)
==56020== by 0x4A5E560: g_object_new (gobject.c:2055)
==56020== by 0x4BF1751: create_new_user (act-user-manager.c:738)
==56020== by 0x4BF7564: act_user_manager_get_user (act-user-manager.c:1982)
==56020== by 0x1134CD: on_user_manager_loaded (im-accounts-service.c:149)
==56020== by 0x4A4C00F: g_closure_invoke (gclosure.c:832)
==56020== by 0x4A793D5: signal_emit_unlocked_R.isra.0 (gsignal.c:3802)
==56020== by 0x4A69699: g_signal_emit_valist (gsignal.c:3555)
```https://gitlab.freedesktop.org/accountsservice/accountsservice/-/issues/106Crash when opening Settings > Users in GNOME OS Nightly2023-03-27T19:38:42ZGhost UserCrash when opening Settings > Users in GNOME OS NightlyHere is the backtrace:
```
(gdb) bt full
#0 g_type_check_instance_is_fundamentally_a (type_instance=type_instance@entry=0x5562fac0ff80, fundamental_type=fundamental_type@entry=0x50 [GObject]) at ../gobject/gtype.c:4152
node = <...Here is the backtrace:
```
(gdb) bt full
#0 g_type_check_instance_is_fundamentally_a (type_instance=type_instance@entry=0x5562fac0ff80, fundamental_type=fundamental_type@entry=0x50 [GObject]) at ../gobject/gtype.c:4152
node = <optimized out>
#1 0x00007fb9ac731334 in g_object_set_data (object=0x5562fac0ff80, key=0x7fb9ab2522bd "fetch-user-request", data=0x0) at ../gobject/gobject.c:4213
_g_boolean_var_152 = <optimized out>
__func__ = "g_object_set_data"
#2 0x00007fb9ab2423d3 in free_fetch_user_request (request=0x5562f8188c80) at ../accountsservice-22.08.8/src/libaccountsservice/act-user-manager.c:1708
manager = 0x5562f7d609b0 [ActUserManager]
priv = 0x5562f7d60900
#3 0x00007fb9ab24314b in fetch_user_incrementally (request=<optimized out>) at ../accountsservice-22.08.8/src/libaccountsservice/act-user-manager.c:1802
priv = <optimized out>
__func__ = "fetch_user_incrementally"
#4 0x00007fb9ab24347e in on_find_user_by_id_finished (object=<optimized out>, result=<optimized out>, data=0x5562f8188c80) at ../accountsservice-22.08.8/src/libaccountsservice/act-user-manager.c:1217
proxy = <optimized out>
request = 0x5562f8188c80
error = 0x0
user = 0x5562fa88b970 "/org/freedesktop/Accounts/User1000"
#5 0x00007fb9ac83241b in g_task_return_now (task=0x5562f8187630 [GTask]) at ../gio/gtask.c:1291
#6 0x00007fb9ac83321b in g_task_return (type=<optimized out>, task=0x5562f8187630 [GTask]) at ../gio/gtask.c:1360
source = 0x7fb998022590
#7 g_task_return (task=0x5562f8187630 [GTask], type=<optimized out>) at ../gio/gtask.c:1317
#8 0x00007fb9ac89e0eb in reply_cb (connection=<optimized out>, res=<optimized out>, user_data=0x5562f8187630) at ../gio/gdbusproxy.c:2578
data = <optimized out>
task = 0x5562f8187630 [GTask]
value = 0x7fb99803f720
error = 0x0
fd_list = 0x0
#9 0x00007fb9ac83241b in g_task_return_now (task=0x5562f8159ec0 [GTask]) at ../gio/gtask.c:1291
#10 0x00007fb9ac83321b in g_task_return (type=<optimized out>, task=0x5562f8159ec0 [GTask]) at ../gio/gtask.c:1360
source = 0x7fb998022590
#11 g_task_return (task=0x5562f8159ec0 [GTask], type=<optimized out>) at ../gio/gtask.c:1317
#12 0x00007fb9ac89168a in g_dbus_connection_call_done (source=<optimized out>, result=0x5562f8166bc0, user_data=0x5562f8159ec0) at ../gio/gdbusconnection.c:5883
connection = <optimized out>
task = 0x5562f8159ec0 [GTask]
state = 0x7fb9900cee20
error = 0x0
reply = 0x7fb99803ebb0 [GDBusMessage]
value = <optimized out>
#13 0x00007fb9ac83241b in g_task_return_now (task=0x5562f8166bc0 [GTask]) at ../gio/gtask.c:1291
#14 0x00007fb9ac832455 in complete_in_idle_cb (task=0x5562f8166bc0) at ../gio/gtask.c:1305
#15 0x00007fb9ac628a21 in g_main_dispatch (context=<optimized out>) at ../glib/gmain.c:3444
dispatch = 0x7fb9ac624790 <g_idle_dispatch>
prev_source = 0x0
begin_time_nsec = 889363081821
was_in_call = 0
user_data = 0x5562f8166bc0
callback = 0x7fb9ac832440 <complete_in_idle_cb>
cb_funcs = 0x7fb9ac70d2e0 <g_source_callback_funcs>
cb_data = 0x5562f7bf9500
need_destroy = <optimized out>
source = 0x7fb998022590
current = 0x5562f7b9c550
i = 0
__func__ = "g_main_dispatch"
#16 g_main_context_dispatch (context=<optimized out>) at ../glib/gmain.c:4162
#17 0x00007fb9ac628f78 in g_main_context_iterate (context=context@entry=0x5562f7b8b830, block=block@entry=1, dispatch=dispatch@entry=1, self=<optimized out>) at ../glib/gmain.c:4238
max_priority = 0
timeout = 0
some_ready = 1
nfds = 4
allocated_nfds = <optimized out>
fds = <optimized out>
begin_time_nsec = 889363062769
#18 0x00007fb9ac629013 in g_main_context_iteration (context=context@entry=0x5562f7b8b830, may_block=may_block@entry=1) at ../glib/gmain.c:4303
retval = <optimized out>
#19 0x00007fb9ac8632ed in g_application_run (application=application@entry=0x5562f7b86fa0 [CcApplication], argc=argc@entry=1, argv=argv@entry=0x7ffe98195038) at ../gio/gapplication.c:2571
arguments = 0x5562f7b4a760
status = 0
context = 0x5562f7b8b830
acquired_context = <optimized out>
__func__ = "g_application_run"
#20 0x00005562f6b27515 in main (argc=1, argv=0x7ffe98195038) at ../shell/main.c:62
application = 0x5562f7b86fa0
```
## Additional info
It was oriented to file the issue here, see: https://gitlab.gnome.org/GNOME/gnome-build-meta/-/issues/581#note_1608685https://gitlab.freedesktop.org/accountsservice/accountsservice/-/issues/103Invalid read of size 8 in on_find_user_by_name_finished2023-03-27T19:30:42ZSebastienInvalid read of size 8 in on_find_user_by_name_finishedThe bug has been reported on https://bugs.launchpad.net/ubuntu/+source/accountsservice/+bug/1966905 using version 22.07.5
```
Valgrind memory errors in gnome-shell 42 from accountsservice:
==60511== Invalid read of size 8
==60511== at ...The bug has been reported on https://bugs.launchpad.net/ubuntu/+source/accountsservice/+bug/1966905 using version 22.07.5
```
Valgrind memory errors in gnome-shell 42 from accountsservice:
==60511== Invalid read of size 8
==60511== at 0x4D207FA: g_type_check_instance_cast (gtype.c:4120)
==60511== by 0x1E421CA2: free_fetch_user_request (act-user-manager.c:1708)
==60511== by 0x1E4298E7: on_find_user_by_name_finished (act-user-manager.c:1187)
==60511== by 0x4BC0C08: g_task_return_now (gtask.c:1230)
==60511== by 0x4BC0E0A: UnknownInlinedFun (gtask.c:1300)
==60511== by 0x4BC0E0A: g_task_return (gtask.c:1256)
==60511== by 0x4C298BA: reply_cb (gdbusproxy.c:2576)
==60511== by 0x4BC0C08: g_task_return_now (gtask.c:1230)
==60511== by 0x4BC0E0A: UnknownInlinedFun (gtask.c:1300)
==60511== by 0x4BC0E0A: g_task_return (gtask.c:1256)
==60511== by 0x4C2107E: g_dbus_connection_call_done (gdbusconnection.c:5895)
==60511== by 0x4BC0C08: g_task_return_now (gtask.c:1230)
==60511== by 0x4BC0C4C: complete_in_idle_cb (gtask.c:1244)
==60511== by 0x4D9CC23: UnknownInlinedFun (gmain.c:3417)
==60511== by 0x4D9CC23: g_main_context_dispatch (gmain.c:4135)
==60511== Address 0x185b5110 is 0 bytes inside a block of size 64 free'd
==60511== at 0x484B27F: free (in /usr/libexec/valgrind/vgpreload_memcheck-amd64-linux.so)
==60511== by 0x4D1F7D4: g_type_free_instance (gtype.c:2008)
==60511== by 0x1E428ECA: UnknownInlinedFun (act-user.c:562)
==60511== by 0x1E428ECA: UnknownInlinedFun (act-user.c:557)
==60511== by 0x1E428ECA: _act_user_update_from_object_path (act-user.c:1346)
==60511== by 0x1E42966F: fetch_user_incrementally (act-user-manager.c:1789)
==60511== by 0x1E4298E7: on_find_user_by_name_finished (act-user-manager.c:1187)
==60511== by 0x4BC0C08: g_task_return_now (gtask.c:1230)
==60511== by 0x4BC0E0A: UnknownInlinedFun (gtask.c:1300)
==60511== by 0x4BC0E0A: g_task_return (gtask.c:1256)
==60511== by 0x4C298BA: reply_cb (gdbusproxy.c:2576)
==60511== by 0x4BC0C08: g_task_return_now (gtask.c:1230)
==60511== by 0x4BC0E0A: UnknownInlinedFun (gtask.c:1300)
==60511== by 0x4BC0E0A: g_task_return (gtask.c:1256)
==60511== by 0x4C2107E: g_dbus_connection_call_done (gdbusconnection.c:5895)
==60511== by 0x4BC0C08: g_task_return_now (gtask.c:1230)
==60511== Block was alloc'd at
==60511== at 0x4848899: malloc (in /usr/libexec/valgrind/vgpreload_memcheck-amd64-linux.so)
==60511== by 0x4DA5718: g_malloc (gmem.c:125)
==60511== by 0x4DBCB64: g_slice_alloc (gslice.c:1072)
==60511== by 0x4DBD1CD: g_slice_alloc0 (gslice.c:1098)
==60511== by 0x4D24E61: g_type_create_instance (gtype.c:1911)
==60511== by 0x4D0BF4C: g_object_new_internal (gobject.c:2011)
==60511== by 0x4D0D1AC: g_object_new_with_properties (gobject.c:2181)
==60511== by 0x4D0DCB0: g_object_new (gobject.c:1821)
==60511== by 0x1E422792: create_new_user (act-user-manager.c:706)
==60511== by 0x1E429BD8: act_user_manager_get_user (act-user-manager.c:1879)
==60511== by 0x68ADE2D: ??? (in /usr/lib/x86_64-linux-gnu/libffi.so.8.1.0)
==60511== by 0x68AA492: ??? (in /usr/lib/x86_64-linux-gnu/libffi.so.8.1.0)
==60511==
==60511== Invalid read of size 8
==60511== at 0x4D206E9: g_type_check_instance_is_fundamentally_a (gtype.c:4091)
==60511== by 0x4D06E9A: g_object_set_data (gobject.c:3982)
==60511== by 0x1E421CB6: free_fetch_user_request (act-user-manager.c:1708)
==60511== by 0x1E4298E7: on_find_user_by_name_finished (act-user-manager.c:1187)
==60511== by 0x4BC0C08: g_task_return_now (gtask.c:1230)
==60511== by 0x4BC0E0A: UnknownInlinedFun (gtask.c:1300)
==60511== by 0x4BC0E0A: g_task_return (gtask.c:1256)
==60511== by 0x4C298BA: reply_cb (gdbusproxy.c:2576)
==60511== by 0x4BC0C08: g_task_return_now (gtask.c:1230)
==60511== by 0x4BC0E0A: UnknownInlinedFun (gtask.c:1300)
==60511== by 0x4BC0E0A: g_task_return (gtask.c:1256)
==60511== by 0x4C2107E: g_dbus_connection_call_done (gdbusconnection.c:5895)
==60511== by 0x4BC0C08: g_task_return_now (gtask.c:1230)
==60511== by 0x4BC0C4C: complete_in_idle_cb (gtask.c:1244)
==60511== Address 0x185b5110 is 0 bytes inside a block of size 64 free'd
==60511== at 0x484B27F: free (in /usr/libexec/valgrind/vgpreload_memcheck-amd64-linux.so)
==60511== by 0x4D1F7D4: g_type_free_instance (gtype.c:2008)
==60511== by 0x1E428ECA: UnknownInlinedFun (act-user.c:562)
==60511== by 0x1E428ECA: UnknownInlinedFun (act-user.c:557)
==60511== by 0x1E428ECA: _act_user_update_from_object_path (act-user.c:1346)
==60511== by 0x1E42966F: fetch_user_incrementally (act-user-manager.c:1789)
==60511== by 0x1E4298E7: on_find_user_by_name_finished (act-user-manager.c:1187)
==60511== by 0x4BC0C08: g_task_return_now (gtask.c:1230)
==60511== by 0x4BC0E0A: UnknownInlinedFun (gtask.c:1300)
==60511== by 0x4BC0E0A: g_task_return (gtask.c:1256)
==60511== by 0x4C298BA: reply_cb (gdbusproxy.c:2576)
==60511== by 0x4BC0C08: g_task_return_now (gtask.c:1230)
==60511== by 0x4BC0E0A: UnknownInlinedFun (gtask.c:1300)
==60511== by 0x4BC0E0A: g_task_return (gtask.c:1256)
==60511== by 0x4C2107E: g_dbus_connection_call_done (gdbusconnection.c:5895)
==60511== by 0x4BC0C08: g_task_return_now (gtask.c:1230)
==60511== Block was alloc'd at
==60511== at 0x4848899: malloc (in /usr/libexec/valgrind/vgpreload_memcheck-amd64-linux.so)
==60511== by 0x4DA5718: g_malloc (gmem.c:125)
==60511== by 0x4DBCB64: g_slice_alloc (gslice.c:1072)
==60511== by 0x4DBD1CD: g_slice_alloc0 (gslice.c:1098)
==60511== by 0x4D24E61: g_type_create_instance (gtype.c:1911)
==60511== by 0x4D0BF4C: g_object_new_internal (gobject.c:2011)
==60511== by 0x4D0D1AC: g_object_new_with_properties (gobject.c:2181)
==60511== by 0x4D0DCB0: g_object_new (gobject.c:1821)
==60511== by 0x1E422792: create_new_user (act-user-manager.c:706)
==60511== by 0x1E429BD8: act_user_manager_get_user (act-user-manager.c:1879)
==60511== by 0x68ADE2D: ??? (in /usr/lib/x86_64-linux-gnu/libffi.so.8.1.0)
==60511== by 0x68AA492: ??? (in /usr/lib/x86_64-linux-gnu/libffi.so.8.1.0)
```https://gitlab.freedesktop.org/accountsservice/accountsservice/-/issues/111Include subprojects in release tarball2023-03-17T14:37:56ZMatt TurnerInclude subprojects in release tarballWithout mocklibc included in the tarball, the build fails if automatic downloads of subprojects are disabled (as they are likely to be in distro build systems):
````
[...]
Program msginit found: YES (/usr/bin/msginit)
Program msgmerge f...Without mocklibc included in the tarball, the build fails if automatic downloads of subprojects are disabled (as they are likely to be in distro build systems):
````
[...]
Program msginit found: YES (/usr/bin/msginit)
Program msgmerge found: YES (/usr/bin/msgmerge)
Program xgettext found: YES (/usr/bin/xgettext)
Program check-format.sh found: YES (/var/tmp/portage/sys-apps/accountsservice-23.11.69/work/accountsservice-23.11.69/tests/check-format.sh)
tests/meson.build:3:0: ERROR: Automatic wrap-based subproject downloading is disabled
````
Meson docs about including subprojects in the release tarball: https://mesonbuild.com/Creating-releases.html#include-subprojects-in-your-releasehttps://gitlab.freedesktop.org/accountsservice/accountsservice/-/issues/110Add support for setting an account as Local in the users file2023-03-15T15:27:57ZJonathan BillingsAdd support for setting an account as Local in the users fileWe have our laptops set up to use IPA for authentication, but the account is set up with a sssd cached password for when off the net, which makes it very much like a local account. Part of our provisioning sets up the account file in /v...We have our laptops set up to use IPA for authentication, but the account is set up with a sssd cached password for when off the net, which makes it very much like a local account. Part of our provisioning sets up the account file in /var/lib/AccountsService/users/ but it seems that you can't set LocalAccount=true in that file.
The reason why we want to allow setting a local account is because if it is not set as local, the Fingerprint settings don't appear in GNOME settings:
https://gitlab.gnome.org/GNOME/gnome-control-center/-/blob/main/panels/user-accounts/cc-user-panel.c#L911
We would like to be able to override the LocalAccount settings in the user config file in /var/lib/AccountsService/users/.
The fix will require adding support for a LocalAccount https://gitlab.freedesktop.org/accountsservice/accountsservice/-/blob/main/src/user.c#L588 passing local here https://gitlab.freedesktop.org/accountsservice/accountsservice/-/blob/main/src/daemon.c#L539 and populating local_users here https://gitlab.freedesktop.org/accountsservice/accountsservice/-/blob/main/src/daemon.c#L332https://gitlab.freedesktop.org/accountsservice/accountsservice/-/issues/52Add lightdm automatic login support2023-02-27T01:35:21ZmouseAdd lightdm automatic login supportAt present, ```accountsservice``` only supports ```GDM``` automatic login.I made changes to ```accountsservice``` add support for ```lightdm```.[accountsservice-0.6.50-lightdm-autologin.patch](/uploads/e8831102e4df1573e913e12ebb4d2d8a/ac...At present, ```accountsservice``` only supports ```GDM``` automatic login.I made changes to ```accountsservice``` add support for ```lightdm```.[accountsservice-0.6.50-lightdm-autologin.patch](/uploads/e8831102e4df1573e913e12ebb4d2d8a/accountsservice-0.6.50-lightdm-autologin.patch)https://gitlab.freedesktop.org/accountsservice/accountsservice/-/issues/107gets confused about local/remote status of users that are considered non-human2023-02-18T00:11:00ZSimon McVittiegets confused about local/remote status of users that are considered non-humanhttps://bugs.debian.org/1030262
To reproduce:
* Be a user with administrative privileges
* Create a new (local, /etc/passwd + /etc/shadow) user account via gnome-control-center, but arrange through devious means for the user account to...https://bugs.debian.org/1030262
To reproduce:
* Be a user with administrative privileges
* Create a new (local, /etc/passwd + /etc/shadow) user account via gnome-control-center, but arrange through devious means for the user account to return false from `user_classify_is_human()`
* In Debian this happened by mistake because we apply patches to use Debian `adduser` instead of `useradd`, and there was a behaviour change in `adduser` causing our accountsservice to be wrongly creating users with `/usr/sbin/nologin`. That's a Debian-specific bug and a fix is in progress, but it demonstrates that this is something that can happen by mistake.
* Upstream, you can probably make this happen by creating a user account with one of the names in `default_excludes[]`. `pvm` is an example of one that is not reserved on my Debian system.
* Upstream, I think you could also make this happen by having 50+ local user accounts already.
* Try to remove the newly-created user via gnome-control-center
* Inspect `/etc/passwd` and `/etc/shadow`
* Log out
* Try to log in as the newly-created-and-then-deleted user using gdm
Expected result:
* accountsservice thinks the user is a local user, because it ... is
* gnome-control-center implements its "Remove User" button as genuinely deleting the local user
* The user is removed from `/etc/passwd` and `/etc/shadow`
* You can't log in as it
Actual result:
* accountsservice thinks the user is a remote user (from LDAP or similar)
* gnome-control-center implements its "Remove User" button as merely removing the user from the cached list of "interesting" users, with an ambiguous message that doesn't make it particularly clear that the user account is not actually being deleted
* The user remains present in `/etc/passwd` and `/etc/shadow`
* gdm doesn't list the user in the shortlist of known users, because accountsservice doesn't list non-human local users unless they're cached
* You can still use "Not listed?" to log in by specifying the user's username
* Potentially a security problem if the reason you were deleting the account is because someone malicious knows its password
I'm reporting this as non-confidential (sorry!) because it's already non-confidential in the Debian bug tracking system.https://gitlab.freedesktop.org/accountsservice/accountsservice/-/issues/109Segfault calling SetRealName on 32-bit ARM2023-02-08T01:10:27ZSimon McVittieSegfault calling SetRealName on 32-bit ARMI added [an integration test](https://salsa.debian.org/freedesktop-team/accountsservice/-/blob/debian/22.08.8-4/debian/tests/integration.py) to Debian's accountsservice packaging, to validate our backports of !118 and !119. This is a des...I added [an integration test](https://salsa.debian.org/freedesktop-team/accountsservice/-/blob/debian/22.08.8-4/debian/tests/integration.py) to Debian's accountsservice packaging, to validate our backports of !118 and !119. This is a destructive "as-installed" test, designed to be run inside an expendable container or virtual machine (it creates and destroys users), so it is not necessarily suitable for upstream inclusion.
This passed on most of our architectures that provide as-installed testing facilities, but failed on armel (ARMv5 EABI softfloat) and armhf (ARMv7 EABI hardfloat) with a segmentation fault in accounts-daemon while handling a call to `SetRealName()`.
On investigation, it looks like this was a format string issue: accounts-daemon uses format `%d` to print a 64-bit integer, resulting in the stack contents not matching what was expected on the two 32-bit ARM architectures. For whatever obscure ABI reason, this didn't crash on i386.
Fixed by !120.Simon McVittieSimon McVittiehttps://gitlab.freedesktop.org/accountsservice/accountsservice/-/issues/108Caching a system (non-human) user causes it to be considered not a system acc...2023-02-06T14:50:06ZSimon McVittieCaching a system (non-human) user causes it to be considered not a system accountWhile adding an integration test to Debian's accountsservice packaging (mainly to verify my backports of !116 and !118), I noticed this behaviour:
* Start with an account that accountsservice considers to be a local system account. I us...While adding an integration test to Debian's accountsservice packaging (mainly to verify my backports of !116 and !118), I noticed this behaviour:
* Start with an account that accountsservice considers to be a local system account. I used `_apt`, a reserved system user that is part of our upgrade mechanism:
```
# grep _apt /etc/passwd
_apt:x:100:65534::/nonexistent:/usr/sbin/nologin
```
* Call `user = AccountsService.UserManager.get_default().cache_user("_apt")` using GObject-Introspection
* Look at its properties with `user.is_system_account()` and so on
* What I expected: `user.is_local_account()` is true, `user.is_system_account()` is also true
* Actual result: `user.is_local_account()` is true (after !116), but `user.is_system_account()` is false
Is this intended?https://gitlab.freedesktop.org/accountsservice/accountsservice/-/issues/8SetPassword causes usermod with password on the command line2023-02-05T19:34:15ZBugzilla Migration UserSetPassword causes usermod with password on the command line## Submitted by Stef Walter
Assigned to **Matthias Clasen `@mclasen`**
**[Link to original bug (#55000)](https://bugs.freedesktop.org/show_bug.cgi?id=55000)**
## Description
Calling SetPassword() on the AccountsService results in ...## Submitted by Stef Walter
Assigned to **Matthias Clasen `@mclasen`**
**[Link to original bug (#55000)](https://bugs.freedesktop.org/show_bug.cgi?id=55000)**
## Description
Calling SetPassword() on the AccountsService results in a crypted password included on the command line. This seems to me to be minor security hole. It is the equivalent of having /etc/shadow readable by non-root users (albeit only for those who change their password via the AccountsService).
Any other local user can (in a default linux configuration) see the command lines of any other process on the system.
The relevant code is in src/user.c in the user_change_password_authorized_cb() function:
argv[0] = "/usr/sbin/usermod";
argv[1] = "-p";
argv[2] = strings[0];
argv[3] = "--";
argv[4] = user->user_name;
argv[5] = NULL;
strings[0] has been set to the crypted password in user_set_password(). The crypted password has been passed from the client (ie: gnome-control-center).https://gitlab.freedesktop.org/accountsservice/accountsservice/-/issues/102accountsservice 22.04.62 fails to start2022-04-11T14:19:43ZDominique Leuenbergeraccountsservice 22.04.62 fails to start```
Mar 27 10:49:57.926295 localhost.localdomain systemd[844]: Failed to mount /run/systemd/unit-root/proc/844/loginuid to /run/systemd/unit-root/proc/844/loginuid: Permission denied
Mar 27 10:49:57.927053 localhost.localdomain systemd[8...```
Mar 27 10:49:57.926295 localhost.localdomain systemd[844]: Failed to mount /run/systemd/unit-root/proc/844/loginuid to /run/systemd/unit-root/proc/844/loginuid: Permission denied
Mar 27 10:49:57.927053 localhost.localdomain systemd[844]: accounts-daemon.service: Failed to set up mount namespacing: /run/systemd/unit-root/proc/844/loginuid: Permission denied
Mar 27 10:49:57.930686 localhost.localdomain systemd[844]: accounts-daemon.service: Failed at step NAMESPACE spawning /usr/libexec/accounts-daemon: Permission denied
Mar 27 10:49:57.934639 localhost.localdomain systemd[1]: accounts-daemon.service: Main process exited, code=exited, status=226/NAMESPACE
Mar 27 10:49:57.934780 localhost.localdomain systemd[1]: accounts-daemon.service: Failed with result 'exit-code'.
Mar 27 10:49:57.935014 localhost.localdomain systemd[1]: Failed to start Accounts Service.
```
This seems to be a regression from https://gitlab.freedesktop.org/accountsservice/accountsservice/-/merge_requests/22 - granted, it's an old MR, but it's only now that this actually was in any released version of accountsservice (so only now shows up)https://gitlab.freedesktop.org/accountsservice/accountsservice/-/issues/104High accounts-daemon CPU usage for frequent logins2022-04-08T19:17:42ZAlkis GeorgopoulosHigh accounts-daemon CPU usage for frequent loginsI'm using lsyncd to sync /home between servers. Due to `UsePAM yes` in sshd_config, this is causing very frequent "root SSH connection logins", where wtmp is updated. So my wtmp grows in size, it's around 100 MB while the largest I've se...I'm using lsyncd to sync /home between servers. Due to `UsePAM yes` in sshd_config, this is causing very frequent "root SSH connection logins", where wtmp is updated. So my wtmp grows in size, it's around 100 MB while the largest I've seen is 765 MB before it got rotated. Judging by the output of `last | wc -l`, it seems that every 100 MB of wtmp size correspond to about 120.000 logins.
Anyway, I think that accounts-daemon might be trying to re-parse the whole wtmp file very frequently, because it's use of CPU is high; for example it needs about one CPU hour for 5 days of uptime.
Would it be possible to lower the CPU usage?
A mitigation was to rotate wtmp more frequently, to keep its size smaller:
```
sed 's/monthly/daily/' -i /etc/logrotate.d/wtmp
```