cosmic-settings
cosmic-settings copied to clipboard
pop-os
Settings > System & Accounts > Users
Users panel provides a way to change user settings and add/remove new users.
State when another user has been added:
I'm just wondering if it's now possible to change my account image, or is it yet to be implemented?
The settings for the page are not implemented yet. They are on the roadmap for alpha 2 release.
it's support for fingerprint/biometrics/pin/passkey planned for user sign in? I see just password accordance in the figma mock-up
I see. Can I change my account image in other way in alpha 1?
I don't know about one right now.
it's support for fingerprint/biometrics/pin/passkey planned for user sign in? I see just password accordance in the figma mock-up
This will be out of scope for the first release but we'll definitely be looking into it in the future.
I see. Can I change my account image in other way in alpha 1?
You can change the users icon by (as root) overwriting the file /var/lib/AccountsService/icons/{user}.
it's support for fingerprint/biometrics/pin/passkey planned for user sign in? I see just password accordance in the figma mock-up
Fingerprint is already supported but setting it currently is up to you as a user. (As root) apt install libpam-fprintd && fprintd-enroll && pam-auth-update.
I see. Can I change my account image in other way in alpha 1?
You can change the users icon by (as root) overwriting the file /var/lib/AccountsService/icons/{user}.
Thank you so much! @jotuel
@Psyhackological No need to use root to change the icon. The icon path is by default defined to point to ~/.face, as defined by Icon= in /var/lib/AccountsService/users/{{user}}.
Cool. :) Mine looks like root@pop-os:~# cat /var/lib/AccountsService/users/jwnz [User] Icon=/var/lib/AccountsService/icons/jwnz SystemAccount=false which explains why a copy of the same photo at $HOME/.face didn't and doesn't work for me.
E. https://github.com/pop-os/cosmic-greeter/blob/ff03667847ee391056fbb69c09e38d5b98c48eda/src/greeter.rs#L89 it would appear that due to this being incomplete a change was made to alpha 1 release.
Hi, I have started implemented that feature, but a few questions arise from the initial work:
- Only custom avatars appears to be designed, but the system should contain a list of predefined avatar in
/usr/share/pixmaps/faces/. Is this coming in phase two? (Can't find a link to the Figma file) - Authentication is suggested only for password and role update. IMHO, allowing username change is a privileged operation as it can cause various security problems. Shall we simply require authentication for any user changes?
- The DBus interface doesn't seem to require any kind of authentication. Does that mean that the locking is only performed on the frontend?
- The authentication popup appears to be a static password authentication, instead of using PAM, which could result in alternative authentication (in my case, fingerprint). Do we expect that lack to be addressed on phase two as well?
- What to do for disabled user and disabling/enabling operation?
Some more technical help - maybe @mmstick you can help again?
- Is there any widget allowing to clip an image into a a shape/rounded rect/circle already or shall I create a component for it?
- Can a symbolic icon be colored with accent color? I'm pretty sure it's possible but I couldn't find an example/doc or make sense of the code.
Here is the current state of progress:
https://github.com/user-attachments/assets/3cc5a4a3-21d4-4bd5-b9c2-2ca2caceec2d
Only custom avatars appears to be designed, but the system should contain a list of predefined avatar in /usr/share/pixmaps/faces/. Is this coming in phase two? (Can't find a link to the Figma file)
Yes, that wasn't planned for first release, but for the second.
The authentication popup appears to be a static password authentication, instead of using PAM, which could result in alternative authentication (in my case, fingerprint). Do we expect that lack to be addressed on phase two as well?
Again, fingerprint was postponed till future releases.
Authentication is suggested only for password and role update. IMHO, allowing username change is a privileged operation as it can cause various security problems. Shall we simply require authentication for any user changes?
What kinds of security problems?
What to do for disabled user and disabling/enabling operation?
Could you go into more detail on the situations when we'd have disabling or disabled users?
What kinds of security problems?
The main concern is deny of service: system authentication requires a valid couple username/password, if an attacker is able to randomize any of these two, then they could prevent access to the machine. This is particularly worrying for user like me, that may have SSH/RDP enabled on their machine so they can acces their machine when they are on the go.
Could you go into more detail on the situations when we'd have disabling or disabled users?
User account may be locked (doc, -L/-U). I appreciate we may not want to include this operational support on phase one, but I'm wondering how to proceed with currently disabled user? Shall we hide them for the list for now? Show them greyed out?
The main concern is deny of service: system authentication requires a valid couple username/password, if an attacker is able to randomize any of these two, then they could prevent access to the machine. This is particularly worrying for user like me, that may have SSH/RDP enabled on their machine so they can acces their machine when they are on the go.
It actually requires valid login/password pair. But we are not talking about changing a users login here though are we? You could not SSH with a name, only with a login. In the greeter you only see a list of names though. So it kind of abstracts away from the user the login. chfn -f
... I appreciate we may not want to include this operational support on phase one ...
Debian system administrators are likely going to keep using better tools for the job like adduser based self build tools and non-technical users are more likely to create problems for themselves than desired outcomes. So the assumption likely is that these are always kept hidden?
how to proceed with currently disabled user?
At this stage maybe it could be wise to just ignore that aspect and list all of the non-system users. But if greying them out would be cheap and simple to do it could be nice. I am just an end-user so you will surely get someones take on this.
But we are not talking about changing a users login here though are we?
It appears this is currently the spec
So the assumption likely is that these are always kept hidden?
I don't quite like the idea of obfuscating the information to the user. Hiding system account definitely makes sense, for the stability reason you've mentioned. Not implementing every single feature of usermod also make sense, but the ability to lock/unlock account is a behaviour that will be useful to non-technical user.
As someone that have been using Linux for the last 15 years, I really would like to see distros becoming more inclusive, and stop segregating users between nerd like us that knows UNIX command line tools, and other :)
In the meantime, I fully endorse the concept of iteration and priority, so if we were to say that it would come later (like fingerprint), this would be completely fair.
jwnz@pop-os:~$ finger jwnz | head -n 1 && finger root | head -n 1
Login: jwnz Name: Joonas Tuomi
Login: root Name: root
We could presume users name and username are different things.
On the second part I hear you. I also believe that if you can muck things up in a GUI you should only ever need GUI to fix your mistakes. Of course this is solvable right: one would only need to always keep track that at least one admin account remains unlocked (and that its password is still known). Then again this is just the thing I came up in a couple of minutes of thinking for an example where an end user would end up in a bad spot. It would just require some testing. Just tried and you can run the command while logged in as the "only user", ill post this before logging out myself.
(like fingerprint)
Well that static password popup most likely is pam and supports fingerprint (depending on your /etc/pam.d/sudo), or at least I am able to just pop my finger in and the pop up disappears. Up to the user to set it up for now.
We could presume users name and username are different things.
Yes, that sounds like a fair assumption, but the Figma design is misleading and just wanted to make sure we get that aligned; for example, d-bus (which we use for backend) exposes UserName and RealName
at least I am able to just pop my finger in and the pop up disappears
This is likely because the application you are using relies on polkit to perform authorization, but it the current Figma design, it suggest to prompt user password directly using a dialog (which may also be a security issue on it's own, but appreciate the v1 step here)
Edit: I checked the default policy installed and it looks like org.freedesktop.login1 and org.freedesktop.account are already locked by it, so for
Does that mean that the locking is only performed on the frontend?
Answer is no! Are we okay to ignore the dialog design for now @maria-komarova ? This likely needs to be implemented somewhere else (~cosmic-comp?~ Edit 2: in cosmic-osd)
Is there "autologin without password" option planed? Or is it something planned in display manager?
Will there be an option to configure group memberships? Please do not go the Gnome e KDE way of removing this functionality.
@acolombier Do you have a branch that you'd like to submit? We are ready to work on this now.
Unfortunately no. Not a Rust developer, yet.
Em qui., 7 de nov. de 2024 às 13:10, Michael Murphy < @.***> escreveu:
@acolombier https://github.com/acolombier Do you have a branch that you'd like to submit? We are ready to work on this now.
— Reply to this email directly, view it on GitHub https://github.com/pop-os/cosmic-settings/issues/443#issuecomment-2462633802, or unsubscribe https://github.com/notifications/unsubscribe-auth/AI7UHQPJYUO4BIFVVLENUIDZ7OGIDAVCNFSM6AAAAABL3NZQMKVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZDINRSGYZTGOBQGI . You are receiving this because you commented.Message ID: @.***>
I do @mmstick - https://github.com/acolombier/cosmic-settings/tree/feat/user-accounts
I just broke it as I tried to rebased it. I'll try to push a fix in the next few hours.
It's only frontend tho, as I didn't know much of how to interact with D-Bus and authentication. I'd be keen to continue working on this tho, in case there is some bits you would be okay to let me help with?
Edit: I have pushed the working version, but the UI now looks quite off compared to the mockup. I assume there was some changes on some of the variable and style classes I was using, but hopefully nothing too hard to fix.