Bug 422177 - New Users kcm doesn't set user avatar as expected
Summary: New Users kcm doesn't set user avatar as expected
Status: RESOLVED FIXED
Alias: None
Product: systemsettings
Classification: Applications
Component: kcm_users (show other bugs)
Version: 5.20.4
Platform: Arch Linux Linux
: HI normal
Target Milestone: ---
Assignee: Plasma Bugs List
URL:
Keywords: regression
: 427731 428446 428653 430579 (view as bug list)
Depends on:
Blocks:
 
Reported: 2020-05-28 13:15 UTC by Patrick Silva
Modified: 2021-05-17 15:24 UTC (History)
19 users (show)

See Also:
Latest Commit:
Version Fixed In: 5.22
Sentry Crash Report:


Attachments
screen recording (2.73 MB, video/webm)
2020-05-28 13:15 UTC, Patrick Silva
Details

Note You need to log in before you can comment on or make changes to this bug.
Description Patrick Silva 2020-05-28 13:15:25 UTC
Created attachment 128859 [details]
screen recording

STEPS TO REPRODUCE
1. open system settings > Users
2. click on your user account
3. click on your current avatar
4. choose a user avatar from the gallery or click on "Choose File..." button
and choose a file from your file system.
5. click on "Apply" button and enter your password to confirm the change

OBSERVED RESULT
If we choose a user avatar from the gallery, the user avatar is not updated in kickoff, screen locker and login manager (sddm).
If we choose a file from the file system, the user avatar is not updated in login manager (sddm).
Watch he attached screen recording please.

EXPECTED RESULT
Users kcm should always set the user avatar correcly in kickoff, screen locker and sddm.

SOFTWARE/OS VERSIONS
Operating System: KDE neon Unstable Edition
KDE Plasma Version: 5.19.80
KDE Frameworks Version: 5.71.0
Qt Version: 5.14.2
Comment 1 Nate Graham 2020-06-10 22:07:57 UTC
Cannot reproduce. Works for me.
Comment 2 Patrick Silva 2020-06-15 23:09:31 UTC
On openSuse krypton, the issue with the avatars from the gallery is also reproducible. Avatar from the file system is set correctly. 
I also noticed that the older User Manager is still present in System Settings of both openSuse Krypton and neon unstable.

Operating System: openSUSE Tumbleweed 20200609
KDE Plasma Version: 5.19.80
KDE Frameworks Version: 5.71.0
Qt Version: 5.15.0
Comment 3 The Feren OS Dev 2020-09-20 15:33:25 UTC
Reproduced on KDE neon Unstable 5.19.90
Comment 4 The Feren OS Dev 2020-09-20 15:34:29 UTC
(although for me it absolutely does not change the avatar at all despite seeming like it did in the KCM - not even .face changes)
Comment 5 David Edmundson 2020-09-24 10:30:59 UTC
Can I have output of "ls ~/.face* " before and after making the change
Comment 6 David Edmundson 2020-09-24 10:32:06 UTC
also somewhere faces get caches into /var    via accounts service. Though I'm not sure off the top of my head where. Can you find that and check the status of that.
Comment 7 Terrance Brown 2020-09-24 10:42:05 UTC
Bug is reproduced for me. Choosing either my own file or one from the gallery and applying it has no effect on the user image in kickoff or the screen locker.

There is no .face image before or after the change according to the output of ls ~/.face* [Might be due to this being a fresh install of non?]

SOFTWARE/OS VERSIONS
Operating System: KDE neon Unstable Edition
KDE Plasma Version: 5.19.90
KDE Frameworks Version: 5.75.0
Qt Version: 5.15.0
Comment 8 Terrance Brown 2020-09-24 10:52:22 UTC
Further info as requested:

Changing my user image was initially done from the standard default avatar to one from the gallery. There was no change to what was shown on the lock screen or in kickoff.

I then changed it from the previously chosen gallery image to my own file. Same as before, the standard user image was shown on the lock screen and in kickoff.

Checking /var/lib/AccountsService only shows Icons [empty for me] and users [inaccessible for me] with no files.
Comment 9 Jan Rathmann 2020-09-24 13:38:25 UTC
Could not reproduce that one on a fresh installation of neon-unstable-20200920-0330.iso on VirtualBox - after modifying the user avatar (gallery or file), the change seems to be applied everywhere.
Comment 10 Nate Graham 2020-09-24 13:39:32 UTC
It's racey or unreliable somehow. It also works for me. But I gather that it doesn't work for everyone.
Comment 11 Alexander Potashev 2020-09-24 19:01:14 UTC
For me on Archlinux and Plasma 5.19.90,
 - The problem is reproducible when I pick from a list of predefined pictures,
 - Not reproducible when I pick choose a custom image from the file system for the avatar. IOW, the avatar on the Launcher menu is changed immediately.

Could be just flaky behavior though.

P.S. The bug got featured here: https://youtu.be/JiY7uRYUiCM?t=776 (although the video doesn't add new info on top of what we already know)
Comment 12 David Redondo 2020-09-24 19:44:06 UTC
I diagnosed the possible reason in https://bugs.kde.org/show_bug.cgi?id=422177
Comment 13 David Redondo 2020-09-24 19:44:33 UTC
(In reply to David Redondo from comment #12)
> I diagnosed the possible reason in
> https://bugs.kde.org/show_bug.cgi?id=422177

I mean https://bugs.kde.org/show_bug.cgi?id=426932
Comment 14 David Redondo 2020-09-24 19:45:16 UTC
*** Bug 426932 has been marked as a duplicate of this bug. ***
Comment 15 Alexander Potashev 2020-09-24 20:22:39 UTC
I think I've found the root cause: AccountsService (https://www.freedesktop.org/wiki/Software/AccountsService/) may set the avatar by updating files in /var/lib/AccountsService/{icons,users}/, while the code in kdeclarative.git/src/qmlcontrols/kcoreaddons/kuserproxy.cpp only reacts to changes in /var/lib/AccountsService/icons/.

I'm not sure, but maybe AccountsService's behavior changed over time:
 - In Plasma 5.18.5 on Fedora I see that for predefined icons, a PNG is being copied into /var/lib/AccountsService/icons/
 - In Plasma 5.19.90 on Archlinux when I pick a predefined icon for avatar, only /var/lib/AccountsService/users/aspotashev would be added, and the dir /var/lib/AccountsService/users/ won't be touched.

----

Now we have at least two options for fixing it:

 1. Hacky approach: Update kdeclarative.git/src/qmlcontrols/kcoreaddons/kuserproxy.cpp to also track /var/lib/AccountsService/users/[loginName] for changes with KDirWatch. This although doesn't protect us from potential future changes in AccountsService's behavior.

 2. Proper fix: Subscribe to D-Bus signal "changed" for the currently logged in user. Can't say for sure if changing the icon would emit the signal though, this needs testing.
Comment 16 Alexander Potashev 2020-09-24 20:25:00 UTC
> I'm not sure, but maybe AccountsService's behavior changed over time:

That said, I believe it's a bug in KF5::Declarative only, not much can be done in Plasma code for 5.20.0.
Comment 17 Alexander Potashev 2020-09-24 20:28:10 UTC
(In reply to Alexander Potashev from comment #15)
> kdeclarative.git/src/qmlcontrols/kcoreaddons/kuserproxy.cpp

To clarify: kdeclarative (part of KF5) is used by Kickoff menu to load the icon and keep it up-to-date in real time. I didn't look into how SDDM and kscreenlocker work, maybe there's another unrelated bug.
Comment 18 David Redondo 2020-09-24 21:32:11 UTC
(In reply to Alexander Potashev from comment #15)

> Now we have at least two options for fixing it:
> 
>  1. Hacky approach: Update
> kdeclarative.git/src/qmlcontrols/kcoreaddons/kuserproxy.cpp to also track
> /var/lib/AccountsService/users/[loginName] for changes with KDirWatch. This
> although doesn't protect us from potential future changes in
> AccountsService's behavior.
I think we don't have the permission to do this
>  2. Proper fix: Subscribe to D-Bus signal "changed" for the currently logged
> in user. Can't say for sure if changing the icon would emit the signal
> though, this needs testing.
Comment 19 Alexander Potashev 2020-09-26 02:26:28 UTC
The different behavior of icon setting for predefined and custom icons can be explained by this block of code:

https://gitlab.freedesktop.org/accountsservice/accountsservice/-/blob/master/src/user.c#L1506
"if ((mode & S_IROTH) == 0 ||"

AccountsService copies the icon into /var/lib/AccountsService/icons/ if it's not universally readable. Other users can't read files in your $HOME, therefore AccountsService will copy the icon and Kickoff will see the new picture immediately.

----

We can apply a workaround to let Kickoff do its job: copy any selected PNG into a file in $HOME where it won't be universally readable (e.g. ~/.face), especially when the user pick a predefined icon.


Maybe we also need to revive this code from the old KCM: https://invent.kde.org/plasma/user-manager/-/blob/master/src/accountinfo.cpp#L184
" //we want to save the face using AccountsService, but for backwards compatibility we also..."
Comment 20 Alexander Potashev 2020-09-26 20:30:49 UTC
The hacky fix will require adding more error handling. Waiting on https://invent.kde.org/plasma/plasma-desktop/-/merge_requests/163 to avoid conflicting changes.
Comment 21 Patrick Silva 2020-10-15 18:08:18 UTC
*** Bug 427731 has been marked as a duplicate of this bug. ***
Comment 22 Nate Graham 2020-10-29 18:55:38 UTC
*** Bug 428446 has been marked as a duplicate of this bug. ***
Comment 23 Guo Yunhe 2020-11-03 08:31:45 UTC
I also cannot update my avatar. My steps:

1. Go to System Settings > User.
2. Choose an avatar from gallery.
3. Save.

Then I check ~/.face and it doesn't exist. SDDM and lock screen doesn't show avatar.

Result is the same when I choose a local image file for avatar.

Operating System: openSUSE Tumbleweed 20201030
KDE Plasma Version: 5.20.2
KDE Frameworks Version: 5.75.0
Qt Version: 5.15.1
Kernel Version: 5.9.1-1-default
OS Type: 64-bit
Processors: 8 × Intel® Core™ i7-8550U CPU @ 1.80GHz
Memory: 31.1 GiB of RAM
Graphics Processor: Mesa DRI Intel® UHD Graphics 620
Comment 24 Guo Yunhe 2020-11-03 08:47:54 UTC
Update:

I tried to set avatar multiple times. Sometimes I can see new avatar take effects in lock screen and SDDM. But sometimes it doesn't.
Comment 25 Patrick Silva 2020-11-03 19:51:30 UTC
*** Bug 428653 has been marked as a duplicate of this bug. ***
Comment 26 Jan 2020-11-03 20:41:40 UTC
I also cannot update my avatar with the newest Plasma, Frameworks and QT - Versions

1. Go to System Settings > User.
2. Choose an avatar from gallery.
3. Save.

Then I check ~/.face and it doesn't exist. SDDM and lock screen doesn't show avatar.

Result is the same when I choose a local image file for avatar.
Linux/KDE Plasma: 
KDE Plasma Version: 5.20.2
KDE Frameworks Version: 5.75
Qt Version: 5.15.1
OS Linux
Platform openSUSE Leap 15.2
Comment 27 Guo Yunhe 2020-11-04 00:23:46 UTC
At least in openSUSE, the avatar is not stored at ~/.face anymore. Here is a DBus protocal to handle the avatar saving. I didn't find out where the avatar is actually stored...
Comment 28 Jon Intxaurbe 2020-12-05 20:30:41 UTC
Is reasonable asking for an administrator's password to change my OWN avatar?
Perhaps it can be because this confirmed bug but I have thought I should tell you about this.

BTW, confirmed too in my system, Operating System: KDE neon 5.20, KDE Plasma Version: 5.20.4, KDE Frameworks Version: 5.76.0, Qt Version: 5.15.1
Comment 29 Nate Graham 2020-12-05 21:09:58 UTC
(In reply to Jon Intxaurbe from comment #28)
> Is reasonable asking for an administrator's password to change my OWN avatar?
That's because it's copying the avatar to a location outside your home folder so that it can be visible to the login screen, because the login screen does not have access to read files inside your home folder.
Comment 30 Dan Robinson 2020-12-17 14:57:58 UTC
Bug exists for me on all of Kubuntu, Arch, and Tumbleweed on fresh installs (i.e., user just created without other stuff in my home directory already).
Comment 31 Nate Graham 2020-12-19 16:40:54 UTC
*** Bug 430579 has been marked as a duplicate of this bug. ***
Comment 32 Alex 2020-12-22 22:00:04 UTC
(In reply to Nate Graham from comment #29)
> (In reply to Jon Intxaurbe from comment #28)
> > Is reasonable asking for an administrator's password to change my OWN avatar?
> That's because it's copying the avatar to a location outside your home
> folder so that it can be visible to the login screen, because the login
> screen does not have access to read files inside your home folder.
I believe that you don't absolutely need admin privileges to change your own data.
https://gitlab.freedesktop.org/accountsservice/accountsservice/-/blob/master/data/org.freedesktop.Accounts.User.xml#L401

I just did a simple test (1):
$ dbus-send --system --dest=org.freedesktop.Accounts --type=method_call --print-reply=literal /org/freedesktop/Accounts/User$UID org.freedesktop.Accounts.User.SetIconFile string:"${HOME}/avatar.png"

It worked like a charm, no questions asked. By the way, the user has neither sudo privileges nor write permissions for /var/lib/AccountsService/icons.

Then I did the same with a world-readable file (2):
$ dbus-send --system --dest=org.freedesktop.Accounts --type=method_call --print-reply=literal /org/freedesktop/Accounts/User$UID org.freedesktop.Accounts.User.SetIconFile string:"/usr/share/sddm/faces/root.face.icon"

The results are somewhat confusing:
- /var/lib/AccountsService/icons/$USER (1) is still in place after (2) and is picked up by kickoff, kscreenlocker and sddm
- /var/lib/AccountsService/users/$USER contains the new (2) icon path and is ignored by kickoff, kscreenlocker and sddm

Plasma: 5.20.4
Frameworks: 5.77.0
AccountsService: 0.6.55
Comment 33 Jon Intxaurbe 2020-12-23 01:49:24 UTC
(In reply to Alex from comment #32)
...> I believe that you don't absolutely need admin privileges to change your own
> data
...

I'm a simple KDE user. I don't have so much technical knowledge. 
Tough in my system at least:
user@Host:/var/lib/AccountsService$ ls -l 
guztira 8 
drwxrwxr-x 2 root root 4096 abe  5 21:28 icons 
drwx------ 2 root root 4096 abe  5 21:28 users
Users don’t have permission to write in that directory. And, of course, I haven't changed permissions.

I’ve checked to change my own icon in system settings again. And password is asked for the change as you can see in these images:
    • https://i.postimg.cc/Pq2pHBhF/User-System-Settings-202012231.pnghttps://i.postimg.cc/B6zjLHjT/User-System-Settings-202012232.pnghttps://i.postimg.cc/3RNyxnxr/User-System-Settings-202012233.pnghttps://i.postimg.cc/cJsgVsqn/User-System-Settings-202012234.pnghttps://i.postimg.cc/D0b8q0Gt/User-System-Settings-202012235.png

It’s strange than in System Settings the icon has changed at the ende, but not in /var/lib/AccountsService/icons nor in kickoff nor in SDDM too.

My Operating System: KDE neon 5.20 (base Ubuntu 20.04)
KDE Plasma Version: 5.20.4
KDE Frameworks Version: 5.77.0
Qt Version: 5.15.2
But it isn’t a new installation. It comes from KDE NEON ¿5.16? based in Ubuntu 18.04 and upgraded later.

I don't want have an argument, of course, not even discuss about it I've related my experience. :-)
Thank you very much for your time and effort. :-)
Comment 34 Jon Intxaurbe 2020-12-23 15:31:24 UTC
(In reply to Jon Intxaurbe from comment #33)

> ...
> 
> I'm a simple KDE user. I don't have so much technical knowledge. 

Excuse me. I've again read my post and I've seen a hard post.
I wasn't angry but tired.
On the other hand, my English level doesn't help.
I'm sorry.
Thank you very much
Comment 35 Alex 2020-12-23 18:25:33 UTC
(In reply to Jon Intxaurbe from comment #33)

Thanks.

It seems that the KCM invokes "SetUserName" and "SetAccountType" even if you don't change the corresponding values.
That's why you actually see "org.freedesktop.accounts.user-administration" in the authentication window.

@Nate Graham
Should I file a separate issue for this?
Comment 36 Dan Robinson 2020-12-24 00:40:47 UTC
Alex, I already filed one for the admin password, 430508. If you want to add that info over there and move that discussion there that would probably be good.
Comment 37 Dan Robinson 2020-12-25 02:32:52 UTC
I manually copied my face icon to ~/.face.icon which caused to appear in Kickoff, and also to /var/lib/AccountsService/icons/<user>.png, and that caused it to work in SDDM too (or techincally ~/.face.icon might have too, I didn't check SDDM before doing both).
Comment 38 luca 2020-12-26 18:47:18 UTC
 
> I just did a simple test (1):
> $ dbus-send --system --dest=org.freedesktop.Accounts --type=method_call
> --print-reply=literal /org/freedesktop/Accounts/User$UID
> org.freedesktop.Accounts.User.SetIconFile string:"${HOME}/avatar.png"
> 
> It worked like a charm, no questions asked. By the way, the user has neither
> sudo privileges nor write permissions for /var/lib/AccountsService/icons.
> 
> Then I did the same with a world-readable file (2):
> $ dbus-send --system --dest=org.freedesktop.Accounts --type=method_call
> --print-reply=literal /org/freedesktop/Accounts/User$UID
> org.freedesktop.Accounts.User.SetIconFile
> string:"/usr/share/sddm/faces/root.face.icon"
> 
> The results are somewhat confusing:
> - /var/lib/AccountsService/icons/$USER (1) is still in place after (2) and
> is picked up by kickoff, kscreenlocker and sddm
> - /var/lib/AccountsService/users/$USER contains the new (2) icon path and is
> ignored by kickoff, kscreenlocker and sddm
> 
> Plasma: 5.20.4
> Frameworks: 5.77.0
> AccountsService: 0.6.55

I can confirm this strange behaviour in Debian Sid and if you link the file (2) in your $HOME it works!
Comment 39 Aurélien Oudelet (auroud85_fr) 2021-01-17 16:47:51 UTC
Accountsservice daemon + Plasma 5.20.4

I can reproduce the bug.

Operating System: Mageia 8
KDE Plasma Version: 5.20.4
KDE Frameworks Version: 5.76.0
Qt Version: 5.15.2
Kernel Version: 5.10.7-desktop-1.mga8
OS Type: 64-bit
Processors: 4 × Intel® Core™ i5-6600K CPU @ 3.50GHz
Memory: 15.6 Gio of RAM
Graphics Processor: GeForce GTX 1660 Ti/PCIe/SSE2
Comment 40 Aurélien Oudelet (auroud85_fr) 2021-02-02 17:13:26 UTC
Following my comment 39,

To workaround this,
1) Choose and copy a png avatar like ones found under
/usr/share/kpackage/kcms/kcm_users/contents/img/

2) Copy/paste chosen PNG file as "~/.face"

3) Make a symlink as:
$ ln -s ./.face ./.face.icon

4) set ACL like this:
$ setfacl -m u:sddm:r ~/.face.icon
$ setfacl -m u:sddm:x ~/

This permits sddm to see your avatar as ".face.icon" in your user root home directory. Why makin a symlink?
For simply change your avatar by only change the ~/.face file.

AccountsService and QML KCM_users are totally broken as is for now.
Comment 41 Patrick Silva 2021-05-17 12:32:51 UTC
On both Arch Linux running Plasma 5.22 beta and neon unstable this bug only affects kickoff launcher,
regardless I set an avatar from gallery or a file. Can anyone confirm? If so, I think we can close this
report because there is a bug report specific for kickoff (see bug 384107).
Comment 42 Nate Graham 2021-05-17 15:24:08 UTC
Can confirm.