search

pop-os / cosmic-settings

COSMIC Settings
GNU General Public License v3.0
167 stars 111 forks source link

Settings > System & Accounts > Users #443

Open maria-komarova opened 3 months ago

maria-komarova commented 3 months ago

Users panel provides a way to change user settings and add/remove new users.

Users-default

State when another user has been added: Users-two-users

Figma file with more details.

Psyhackological commented 3 months ago

I'm just wondering if it's now possible to change my account image, or is it yet to be implemented? screenshot-2024-08-15-10-14-00

maria-komarova commented 3 months ago

The settings for the page are not implemented yet. They are on the roadmap for alpha 2 release.

Psyhackological commented 3 months ago

I see. Can I change my account image in other way in alpha 1?

rohmishra commented 3 months ago

it's support for fingerprint/biometrics/pin/passkey planned for user sign in? I see just password accordance in the figma mock-up

maria-komarova commented 3 months ago

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.

jotuel commented 2 months ago

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.

Psyhackological commented 2 months ago

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

mmstick commented 2 months ago

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

jotuel commented 2 months ago

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.

acolombier commented 2 months ago

Hi, I have started implemented that feature, but a few questions arise from the initial work:

Some more technical help - maybe @mmstick you can help again?

Here is the current state of progress:

https://github.com/user-attachments/assets/3cc5a4a3-21d4-4bd5-b9c2-2ca2caceec2d

maria-komarova commented 2 months ago

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?

acolombier commented 2 months ago

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?

jotuel commented 2 months ago

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.

acolombier commented 2 months ago

But we are not talking about changing a users login here though are we?

It appears this is currently the spec

image

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.

jotuel commented 2 months ago 
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.

acolombier commented 2 months ago

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)

dragon99919 commented 1 month ago

Is there "autologin without password" option planed? Or is it something planned in display manager?

maria-komarova commented 1 month ago

Planned for after the first release.

UMineiro commented 3 weeks ago

Will there be an option to configure group memberships? Please do not go the Gnome e KDE way of removing this functionality.

mmstick commented 3 weeks ago

@acolombier Do you have a branch that you'd like to submit? We are ready to work on this now.

UMineiro commented 3 weeks ago

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: @.***>

acolombier commented 3 weeks ago

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.