Bug 422177

Cannot reproduce. Works for me.

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

Reproduced on KDE neon Unstable 5.19.90

(although for me it absolutely does not change the avatar at all despite seeming like it did in the KCM - not even .face changes)

Can I have output of "ls ~/.face* " before and after making the change

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.

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

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.

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.

It's racey or unreliable somehow. It also works for me. But I gather that it doesn't work for everyone.

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)

I diagnosed the possible reason in https://bugs.kde.org/show_bug.cgi?id=422177

(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

*** Bug 426932 has been marked as a duplicate of this bug. ***

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.

> 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.

(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.

(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.

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..."

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.

*** Bug 427731 has been marked as a duplicate of this bug. ***

*** Bug 428446 has been marked as a duplicate of this bug. ***

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

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.

*** Bug 428653 has been marked as a duplicate of this bug. ***

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

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...

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

(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.

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).

*** Bug 430579 has been marked as a duplicate of this bug. ***

(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

(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.png
    • https://i.postimg.cc/B6zjLHjT/User-System-Settings-202012232.png
    • https://i.postimg.cc/3RNyxnxr/User-System-Settings-202012233.png
    • https://i.postimg.cc/cJsgVsqn/User-System-Settings-202012234.png
    • https://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. :-)

(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

(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?

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.

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).

 
> 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!

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

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.

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).

Can confirm.