Settings issueshttps://gitlab.gnome.org/GNOME/gnome-control-center/-/issues2024-02-22T07:55:03Zhttps://gitlab.gnome.org/GNOME/gnome-control-center/-/issues/2918Improve hostname handing in Add Enterprise Login dialog2024-02-22T07:55:03ZOndrej HolyImprove hostname handing in Add Enterprise Login dialogThe Initial Setup app allows you to change the hostname in the Enroll dialog. The Add Enterprise Login dialog doesn't have this option. We should improve it somehow because one has to use cmd now to achieve this...
Though there is a pos...The Initial Setup app allows you to change the hostname in the Enroll dialog. The Add Enterprise Login dialog doesn't have this option. We should improve it somehow because one has to use cmd now to achieve this...
Though there is a possibility to change the hostname over the About page, it is not possible to change it to be fully qualified (e.g. `mydevice.domain.com`). The `.` characters are replaced by `_`, which doesn't work. This needs to be fixed. But even if it would work it would not be ideal as one loses all the data entered in the Add Enterprise Login dialog.
(This is follow-up from https://gitlab.gnome.org/GNOME/gnome-control-center/-/merge_requests/2098#note_1951214).https://gitlab.gnome.org/GNOME/gnome-control-center/-/issues/2820Users: panel appears in a weird way for less than one second2024-01-22T16:55:48ZAutomeris naranjaUsers: panel appears in a weird way for less than one second## Affected version
gnome-control-center-45.2-1.fc39.x86_64
## Description
When opening the Users panel, all rows, including ones that should only appear in a specific context (like the "Language" and "Fingerprint Login" rows) appear ...## Affected version
gnome-control-center-45.2-1.fc39.x86_64
## Description
When opening the Users panel, all rows, including ones that should only appear in a specific context (like the "Language" and "Fingerprint Login" rows) appear very shortly; this is more noticeable when opening Settings for the first time after a cold boot. Also, my name and avatar don't show; instead, I see a "placeholder" panel or something:
![Screencast_from_2024-01-04_20-39-04](/uploads/e0a950176c9969a03dbf1823dda66908/Screencast_from_2024-01-04_20-39-04.webm)
![image](/uploads/fd74c6a9910b309dbe242b2ec38ea7ce/image.png){width="403" height="226"}GNOME 45https://gitlab.gnome.org/GNOME/gnome-control-center/-/issues/2713Improve UX for Enterprise Login/Realm configuration2023-11-09T14:42:22ZCedric SodhiImprove UX for Enterprise Login/Realm configurationWhile there are some facilities to work with realms/Kerberos/AD/... in GNOME Settings, the setup of "Enterprise Login" seems to default to "permit by user", rather than "permit all from domain", meaning that each user has to be added man...While there are some facilities to work with realms/Kerberos/AD/... in GNOME Settings, the setup of "Enterprise Login" seems to default to "permit by user", rather than "permit all from domain", meaning that each user has to be added manually through "add user" before they can use their domain account to log in. Additionally, adding a user from the domain seems to require the user's password in the UI, such that users can't be permitted in advance.
It would be nice if the realm could at least be configured to "permit all from domain", because otherwise one has to resort to CLI usage of `realm` anyway.https://gitlab.gnome.org/GNOME/gnome-control-center/-/issues/2612Fingerprint Login menu doesn't appear if Settings started with Search --> Users2023-08-25T12:13:30ZMark KohlerFingerprint Login menu doesn't appear if Settings started with Search --> Users<!--
Not following the communication guidelines [1] will mean your issue or comment
will be removed. Read it carefully before submitting this issue.
[1] https://gitlab.gnome.org/GNOME/gnome-control-center/blob/main/docs/CODE_OF_CONDUCT...<!--
Not following the communication guidelines [1] will mean your issue or comment
will be removed. Read it carefully before submitting this issue.
[1] https://gitlab.gnome.org/GNOME/gnome-control-center/blob/main/docs/CODE_OF_CONDUCT.md#communication-guidelines
Detailed description of the issue. Put as much information as you can, potentially
with images showing the issue.
-->
## Relevant information
* GNOME Settings version 44.1
<!-- Find with the command "gnome-control-center --version" -->
* Operating system (distribution) NixOS 23.05
<!-- Find with the command "cat /etc/os-release" -->
* Hardware Framework 13 laptop
* Screenshots
![started_with_Search_then_Settings](/uploads/764ed083b36373840213eec3cf2aac31/started_with_Search_then_Settings.png)
![started_with_Search_then_Users](/uploads/6a05c1ffe5b9afa9b2595a1d68a00cbc/started_with_Search_then_Users.png)
## Steps to reproduce:
0. If it is open, close the Gnome Settings app.
1. Click the Super/Windows button to start Search.
2. Type Settings.
3. Click on Users on the left-side menu.
4. Notice that there is a Fingerprint Login Menu. (see screenshot)
5. Close the Gnome Settings app.
6. Click the Super/Windows button to start Search.
7. Type Users.
8. Notice that there is no Finger Login Menu. (see screenshot)https://gitlab.gnome.org/GNOME/gnome-control-center/-/issues/2559gnome-control-center crashes when attempting to select an image file2023-09-07T10:45:15ZAssaf Hershkognome-control-center crashes when attempting to select an image fileSystem:
EndeavourOS. Latest version, fully updated. Nvidia graphics. Wayland.
Steps to reproduce:
1. Open GNOME Settings.
2. Select "Users" on the left side bar.
3. Click on the edit icon for the user image.
4. In the popup dialog, cli...System:
EndeavourOS. Latest version, fully updated. Nvidia graphics. Wayland.
Steps to reproduce:
1. Open GNOME Settings.
2. Select "Users" on the left side bar.
3. Click on the edit icon for the user image.
4. In the popup dialog, click on "Select a File...".
5. The setting app closes silently and completely (presumably crashes), instead of showing a file selection dialog.
Hint:
I have two monitors, with fractional scaling on. One monitor scales to 125%, the other to 100%.
If the settings window is on the monitor that scales to 100% it works fine. It crashes (when I click on "Select a File..." as per the above steps) only if it's on the monitor that scales to 125%.https://gitlab.gnome.org/GNOME/gnome-control-center/-/issues/2515Users: when setting a custom profile picture, the select button doesn't use t...2023-11-10T20:32:19ZAutomeris naranjaUsers: when setting a custom profile picture, the select button doesn't use the ".suggested-action" style class## Affected version
gnome-control-center-44.1-1.fc38.x86_64
## Steps to reproduce
1. Go to Users
2. Click in the edit button from the profile picture > select file
## Seen behavior
The select button background isn't blue. In other w...## Affected version
gnome-control-center-44.1-1.fc38.x86_64
## Steps to reproduce
1. Go to Users
2. Click in the edit button from the profile picture > select file
## Seen behavior
The select button background isn't blue. In other words, it doesn't use the `.suggested-action` style class:
![Screenshot_from_2023-05-30_22-33-17](/uploads/bb142cb0e8a1105b0f8548a2380bcfe3/Screenshot_from_2023-05-30_22-33-17.png)
Example of a button using `.suggested-action`:
![Screenshot_from_2023-05-30_22-43-15](/uploads/abc8fda5706641613064472184c8a8c7/Screenshot_from_2023-05-30_22-43-15.png)
The code for this dialog live [in this area](https://gitlab.gnome.org/GNOME/gnome-control-center/-/blob/main/panels/user-accounts/cc-avatar-chooser.c). Unfortunately, I don't know how to set this style class in C. :(https://gitlab.gnome.org/GNOME/gnome-control-center/-/issues/2460Creatin user account does not transfer home directory ownership2023-06-27T03:31:15ZAurimas ČerniusCreatin user account does not transfer home directory ownershipScenario: I "upgraded" my OS by doing a new install, just keeping the /home partition intact.
On first launch I was prompted to create new user, which I did, but I made a mistake in user name, so new folder in /home is created rather tha...Scenario: I "upgraded" my OS by doing a new install, just keeping the /home partition intact.
On first launch I was prompted to create new user, which I did, but I made a mistake in user name, so new folder in /home is created rather than reusing the old one. So I launch Settings to create a new user with correct username to restore my system. When I log into this new user, all seems lost and File can't open home directory. The reason is that home directory does not belong to this newly created user, so no access rights.
When user with correct name is create in first run screen, the home folder is reused and ownership is properly transferred to new user.
Steps to reproduce:
1. Make a directory in /home that is owned by some user on the system
2. Open GNOME Settings
2. Go to user account pane
3. Unlock and add new user with username matching the directory you've made in /home
Expected: either error or suggestion to change ownership of directory and all it's contents recursively
Actual: user is created, home directory reused, but user has no access to home directory
Workaround: "sudo chown..." to recursively change directory ownership.https://gitlab.gnome.org/GNOME/gnome-control-center/-/issues/2326users: Not clear about the difference between deleting local and remote users2023-02-02T00:13:53ZSimon McVittieusers: Not clear about the difference between deleting local and remote usersTo reproduce:
* Have a user that accountsservice considers to be local, let's say `localuser`
* Have another user that accountsservice considers to be remote (LDAP or similar), let's say `remoteuser`
* Unlock the users panel
* For each ...To reproduce:
* Have a user that accountsservice considers to be local, let's say `localuser`
* Have another user that accountsservice considers to be remote (LDAP or similar), let's say `remoteuser`
* Unlock the users panel
* For each of those users:
* Mouse over "Remove user" button
* Click "Remove user" button
Expected result:
* For `localuser`, what is going to happen is that the account will be deleted from `/etc/passwd` and `/etc/shadow`, and optionally the user's home directory will be deleted
* For `remoteuser`, what is going to happen is that the account will disappear from the cached list of "interesting" remote accounts, but it will probably still be possible for `remoteuser` to log in to your computer (for example using the "Not listed?" button in gdm)
* The buttons and tooltips should reflect that
* The "are you sure?" prompt should also reflect that
* Nice to have: some sort of indication (banner or icon or similar) that `remoteuser` is coming from a remote user directory and so the edits you will be able to do to it are likely to be limited
Actual result as of 43.0 (I haven't checked 44 prereleases):
* There is no indication (banner or icon or similar) that `remoteuser` is coming from a remote user directory
* In both cases the button is titled "Remove user"
* In both cases the tooltip is "Delete the selected user account"
* For `localuser`, the "are you sure?" prompt is as shown in #2093, which is not perfect, but it's reasonably clear about what is going to happen.
* For `remoteuser`, the "are you sure?" prompt says: "Are you sure you want to revoke remotely managed remoteuser's account?". That uses the word "revoke" which makes me think "this is an authorization change, locking the user out", but that's not the case: the underlying accountsservice action is to "uncache" the user, which takes them off the shortlist on the gdm login screen but doesn't affect authorization.
The mockup on #2093 looks like an improvement for the `localuser` case, but I don't think it's a prerequisite for resolving this issue. My main concern here is the UX when the user is (or appears to be) remotely managed.
The reason I'm seeing this now is some orthogonal bugs in (Debian's patched version of) accountsservice: <https://bugs.debian.org/1030253> which is Debian-specific, triggering https://gitlab.freedesktop.org/accountsservice/accountsservice/-/issues/107 which is not. These two bugs combine to get a local user account that accountsservice thinks is remote, and when that is combined with the gnome-control-center UI not being as clear as it could be, the result is that a user thinks they have deleted an account but then can still log in as that account (<https://bugs.debian.org/1030262>). Obviously that's mostly not gnome-control-center's fault, but if the remote-account UX was clearer, it would avoid misleading the user into thinking they had genuinely removed access.https://gitlab.gnome.org/GNOME/gnome-control-center/-/issues/2305Fingerprint options going off-screen on high resolution scaled display2023-01-16T19:50:54ZGhost UserFingerprint options going off-screen on high resolution scaled displayWhen I open the fingerprint options on my higher resolution scaled display and click 'scan new fingerprint' the options go off-screen
![image](/uploads/3e8877b5b307b4a38012766ae6f84dba/image.png)
Steps to reproduce:
1. Open GNOME Setti...When I open the fingerprint options on my higher resolution scaled display and click 'scan new fingerprint' the options go off-screen
![image](/uploads/3e8877b5b307b4a38012766ae6f84dba/image.png)
Steps to reproduce:
1. Open GNOME Settings on a scaled display (I used 2x)
2. Go to 'Users'
3. Click the 'Fingerprint Login' option
4. Click 'Scan new fingerprint'
the drop down goes off-screenhttps://gitlab.gnome.org/GNOME/gnome-control-center/-/issues/2224Users: fingerprint dialog isn't using AdwStatusPage2023-05-17T23:43:05ZGhost UserUsers: fingerprint dialog isn't using AdwStatusPageThis can be seen at: https://gitlab.gnome.org/GNOME/gnome-control-center/-/blob/gnome-43/panels/user-accounts/cc-fingerprint-dialog.ui#L158
## Additional info
- GNOME Settings 43.2This can be seen at: https://gitlab.gnome.org/GNOME/gnome-control-center/-/blob/gnome-43/panels/user-accounts/cc-fingerprint-dialog.ui#L158
## Additional info
- GNOME Settings 43.2https://gitlab.gnome.org/GNOME/gnome-control-center/-/issues/2185Users: add a login screen configuration preference2024-02-22T02:49:48ZAllan DayUsers: add a login screen configuration preferenceWe currently have very limited support for configuring the login screen and, in most cases, there's no way to change how the login screen is configured.
The relevant settings for the login screen are everything under region & language, ...We currently have very limited support for configuring the login screen and, in most cases, there's no way to change how the login screen is configured.
The relevant settings for the login screen are everything under region & language, displays, mouse & touchpad, and accessibility. Input sources probably need their own special handling.
A tentative approach to this problem might be:
1. When there's just one user, copy any relevant settings from the user session to gdm
2. When there's more than one user, expose a "Login Screen" option, which determines which user's settings should be used for the login screen
This can be seen in the latest [user settings mockups](https://gitlab.gnome.org/Teams/Design/settings-mockups/-/blob/master/users/users.png).https://gitlab.gnome.org/GNOME/gnome-control-center/-/issues/2145The "authentication required" dialog appears repeatedly2023-01-04T09:27:14ZGhost UserThe "authentication required" dialog appears repeatedly## Steps to reproduce
1. Change the user password
2. Restart the session
or
1. Change the system language
2. Restart the session
## Seen behavior
The following dialog will appear:
![Screenshot_from_2022-11-19_19-32-42](/uploads/10110...## Steps to reproduce
1. Change the user password
2. Restart the session
or
1. Change the system language
2. Restart the session
## Seen behavior
The following dialog will appear:
![Screenshot_from_2022-11-19_19-32-42](/uploads/10110392e671e2cac85a29179d21f724/Screenshot_from_2022-11-19_19-32-42.png)
Putting the new or the old password doesn't work and it's necessary to click in "Cancel" multiple times to get rid of this. Also, it reappears in the next session.
## Additional information
- ~~Deleting `login.keyring` and `user.keystore` files in `~/.local/share/keyrings` seems to fix the issue~~ Deleting `login.keyring` and `user.keystore` isn't working anymore, the problem has returned. That's weird because it did work in the past. This also happens when changing the system language, but I'm not sure if I should file a separate issue for this.
- gnome-control-center-43.1-1.fc37.x86_64https://gitlab.gnome.org/GNOME/gnome-control-center/-/issues/2121Avatar selection widget is not scrollable2023-05-10T14:06:21ZViorel-Cătălin RăpițeanuAvatar selection widget is not scrollableDescription:
The avatar selection widget is not scrollable. This makes it unusable when it's used on small screen devices.
Versions:
* gnome-shell: latest
* gnome-settings-daemon: 42.2
* OS: postmarketOS edge Gnome Shell
Hardware:
*...Description:
The avatar selection widget is not scrollable. This makes it unusable when it's used on small screen devices.
Versions:
* gnome-shell: latest
* gnome-settings-daemon: 42.2
* OS: postmarketOS edge Gnome Shell
Hardware:
* Device: Pinephone Pro
* Resolution: 1440 x 720 (160.8 x 76.6 x 11.1mm) (https://www.pine64.org/pinephonepro/)
Picture:
![avatar-selection](/uploads/fbe0574200a5bf317bcacc53293ffd63/avatar-selection.png)https://gitlab.gnome.org/GNOME/gnome-control-center/-/issues/2095Users: update the add user dialog2024-03-14T15:05:37ZAllan DayUsers: update the add user dialogThe add user dialog currently looks like this:
![image](/uploads/951543ebb2b811b5ff2927adf2e6e6c8/image.png)
It's quite long and haphazard. The entries should really use AdwEntryRow.
I've done [some new mockups](https://gitlab.gnome.o...The add user dialog currently looks like this:
![image](/uploads/951543ebb2b811b5ff2927adf2e6e6c8/image.png)
It's quite long and haphazard. The entries should really use AdwEntryRow.
I've done [some new mockups](https://gitlab.gnome.org/Teams/Design/settings-mockups/-/blob/master/users/add-user.png) which do this, and generally tidy up the dialog. They involve splitting the dialog into two steps, with the second used for setting a password. They also involve splitting out [enterprise login](https://gitlab.gnome.org/Teams/Design/settings-mockups/-/blob/master/users/add-enterprise-login.png) into its own dialog.Felipe Borgesfelipeborges@gnome.orgFelipe Borgesfelipeborges@gnome.orghttps://gitlab.gnome.org/GNOME/gnome-control-center/-/issues/2094Users: unclear field validity when changing password2022-10-17T15:26:49ZAllan DayUsers: unclear field validity when changing password![image](/uploads/88b6b06f2a7e31198c1fdd0d86a2659f/image.png)
It's not very clear that current password is invalid. There's also no indication that the new password is valid. This could lead to confusing situations, where the change but...![image](/uploads/88b6b06f2a7e31198c1fdd0d86a2659f/image.png)
It's not very clear that current password is invalid. There's also no indication that the new password is valid. This could lead to confusing situations, where the change button is insensitive, but it's not clear why.
The [latest designs](https://gitlab.gnome.org/Teams/Design/settings-mockups/-/blob/master/users/users.png) include mockups address this issue:
![image](/uploads/03d51f9463feccf6215a51dec1de54a7/image.png)https://gitlab.gnome.org/GNOME/gnome-control-center/-/issues/1982Fingerprint enrollment offerings incorrect2023-12-16T19:16:06ZMark PearsonFingerprint enrollment offerings incorrectUsing Fedora36 latest (as of 25th July 2022) on a Z13.
- enroll the right index finger
- enroll another finger. The right index finger is still offered as an option (despite already being enrolled). The left little finger is not.
If y...Using Fedora36 latest (as of 25th July 2022) on a Z13.
- enroll the right index finger
- enroll another finger. The right index finger is still offered as an option (despite already being enrolled). The left little finger is not.
If you then enroll another finger that will be offered but another finger will not.
Somewhat related - it would also be great to have the right hand offered before the left hand (on all models I know of the fingerprint reader is on the right hand side and therefore right hand is more likely to be used). I would also offer the index fingers as the first option as they're the usual choice.
Steps to reproduce:
1. Open GNOME Settings
2. Go to fingerprint setup
3. Register right index finger
4. add another finger - check what options are offered.GNOME 44Felipe Borgesfelipeborges@gnome.orgFelipe Borgesfelipeborges@gnome.orghttps://gitlab.gnome.org/GNOME/gnome-control-center/-/issues/1924Fingerprints get deleted if I fail to get the fingerprint reading correct2022-09-14T12:25:01ZRichard QuinlivanFingerprints get deleted if I fail to get the fingerprint reading correctThe fingerprints that I have saved on my laptop get deleted when I try to use the fingerprint reader. I also only get one try to get the fingerprint sensor to work when I log in. There is no prompt to try again and the initial prompt goe...The fingerprints that I have saved on my laptop get deleted when I try to use the fingerprint reader. I also only get one try to get the fingerprint sensor to work when I log in. There is no prompt to try again and the initial prompt goes away.
I'm Using Fedora 36 with Gnome 42.2. My fingerprint reader is a Goodix MOC Fingerprint sensor, and I'm using a Framework laptop.
Steps to reproduce.
1. Add a fingerprint to the user
2. Restart the laptop
3. Use a different finger with the sensor or place the correct finger at a bad angle. Basically, get the reading to fail
4. Go to User settings and see that the fingerprint reader is now disabled
![image](/uploads/231244c8b78c30c3378818003d24e97a/image.png)
Also, not sure if this is relevant, or just a separate thing, but I have been getting this occasionally as well when trying to add fingerprints. Restarting makes it go away.
![image](/uploads/9a55fc9694a85ea6c2fa9865ae2427f5/image.png)https://gitlab.gnome.org/GNOME/gnome-control-center/-/issues/1816Gnome Settings fingerprint issue2022-12-12T09:34:51ZKelvinnkatGnome Settings fingerprint issueHello! I'm running Fedora 36 and Gnome 42.1 and I've been having a series of issues relating to Gnome settings' Users panel and fingerprints in particular. What happened was that I enrolled my right index finger through fprintd-enroll in...Hello! I'm running Fedora 36 and Gnome 42.1 and I've been having a series of issues relating to Gnome settings' Users panel and fingerprints in particular. What happened was that I enrolled my right index finger through fprintd-enroll in the terminal, but then when I tried to add it to my Users page it told me that it could not enroll my fingerprint. However, other fingerprints worked fine in the Users panel, it was only the one that was enrolled through fprintd that didn't. I uninstalled and reinstalled fprintd, only to find that after restarting my computer fprintd worked fine through the terminal, but fingerprints were not an option anymore in GNOME settings' Users tab. Additionally, the following error messages appeared:
(gnome-control-center:31843): user-accounts-cc-panel-WARNING **: 16:33:28.957: Error retrieving app filter for user (null): User 4294967295 does not exist
(gnome-control-center:31843): Gtk-CRITICAL **: 16:33:28.964: Unable to register the application: GDBus.Error:org.freedesktop.DBus.Error.NameHasNoOwner: Could not activate remote peer.
Note, @apollo13 referred me here, not sure if that makes a difference.
Steps to reproduce:
1. Run sudo dnf remove fprintd
2. Run sudo dnf install fprintd (not sure if this affects the result)
3. Restart (not sure if that affects the result)
4. Open Gnome settings, and open the users tab, typing in your password if needed
5. Check for Fingerprints optionhttps://gitlab.gnome.org/GNOME/gnome-control-center/-/issues/1790Support setting up PAM for users Authentication & Login2023-09-29T04:10:47ZAntoine RAYNARDSupport setting up PAM for users Authentication & Login<!--
Not following the communication guidelines [1] will mean your issue or comment
will be removed. Read it carefully before submitting this issue.
[1] https://gitlab.gnome.org/GNOME/gnome-control-center/blob/master/docs/CONTRIBUTING...<!--
Not following the communication guidelines [1] will mean your issue or comment
will be removed. Read it carefully before submitting this issue.
[1] https://gitlab.gnome.org/GNOME/gnome-control-center/blob/master/docs/CONTRIBUTING.md#communication-guideline
-->
Add "Pluggable Authentication Module" (PAM) configuration options to the section Users/Authtication & Login, to ease setting up a FIDO2/U2F security key for login (e.g: Solokeys, YubiKey).
Proposed Mockups:
![gnome-settings-pam-mockup](/uploads/92b3a67eba48662af0cbdcdba0dc906d/gnome-settings-pam-mockup.png)
Security Key login option, following the same style as the Fingerprint option
![gnome-settings-pam-mockup2](/uploads/de8f10c594736d05d8ca32a2e958b2a2/gnome-settings-pam-mockup2.png)
Manage/add security keys dialog, following the same style as the Fingerprint dialog
## Design Tasks
* [ ] Design Security Key Manage/add dialog following the same style as the Fingerprint dialog
## Development Tasks
* [ ] Add new menu entry to Authentication & Login
* [ ] Detect the presence of a Security Key
* [ ] Register a key
* [ ] Configure PAM [c.f: Security, 3.2 PAM | Help gnome.org](https://help.gnome.org/admin/gdm/stable/security.html.en#PAM)
## QA Tasks
* [ ] Test with Solokeys
* [ ] Test with YubiKey
* [ ] Test with Nitrokeyhttps://gitlab.gnome.org/GNOME/gnome-control-center/-/issues/1629User profile picture can't be set to an own picture file, because /tmp is not...2022-05-13T15:09:14ZFabian BornscheinUser profile picture can't be set to an own picture file, because /tmp is not readable by accountsservicesSince this is a bug between G-C-C and [accountsservice](https://gitlab.freedesktop.org/accountsservice/accountsservice) I don't know where to report it. So it's reported on both ends now. I hope this is OK.
Upstream conflict: https://gi...Since this is a bug between G-C-C and [accountsservice](https://gitlab.freedesktop.org/accountsservice/accountsservice) I don't know where to report it. So it's reported on both ends now. I hope this is OK.
Upstream conflict: https://gitlab.freedesktop.org/accountsservice/accountsservice/-/issues/98
## What's wrong?
If you try to use an own user picture, G-C-C writes a temporary picture file to /tmp, and calls accountsservices via dbus. Accountsservices however is unable to read pictures (or anything else) from /tmp (see upstream conflict)
## Reproduce with
1. Open Settings app
2. Go to the user settings part
3. Click on the display picture (to change it)
4. Click on "Choose a file"
5. Now choose a picture
### What happens?
This
```
(gnome-control-center:7861): accountsservice-WARNING **: 15:32:07.674: SetIconFile call failed: GDBus.Error:org.freedesktop.Accounts.Error.Failed: file '/tmp/gnome-control-center-user-icon-LR33G1' is not a regular file
```
Info about my system
* ArchLinux
* accountsservice 22.04.62
* gnome-shell 41.3
* gtk3 3.24.31
* gnome-control-center 41.2Felipe Borgesfelipeborges@gnome.orgFelipe Borgesfelipeborges@gnome.org