From Fedora Project Wiki
 
(21 intermediate revisions by 5 users not shown)
Line 11: Line 11:
== Current status ==
== Current status ==
* Targeted release: [[Releases/13 | Fedora 13 ]]  
* Targeted release: [[Releases/13 | Fedora 13 ]]  
* Last updated: 2010-10-12
* Last updated: 2010-03-30
* Percentage of completion: 40%
* Percentage of completion: 100%


We have lots of (somewhat dated) design and scoping work that was done in Spring 2008: http://people.redhat.com/mclasen/user-account3.pdf.bz2. Here are some more sketches from back then: http://fedoraproject.org/wiki/Features/ImprovedUserManagementUI. Glade files for some of the mockups are here: http://people.fedoraproject.org/~mccann/design/user_accounts/. Earlier discussion around this idea happened here: https://www.redhat.com/archives/fedora-desktop-list/2008-May/msg00006.html
We have lots of (somewhat dated) design and scoping work that was done in Spring 2008: http://people.redhat.com/mclasen/user-account3.pdf.bz2. Here are some more sketches from back then: http://fedoraproject.org/wiki/Features/ImprovedUserManagementUI. Glade files for some of the mockups are here: http://people.fedoraproject.org/~mccann/design/user_accounts/. Earlier discussion around this idea happened here: https://www.redhat.com/archives/fedora-desktop-list/2008-May/msg00006.html
Line 18: Line 18:
Ubuntu seem to be plan working on something similar, see https://wiki.ubuntu.com/DesktopTeam/Specs/Lucid/UserAccountManagement
Ubuntu seem to be plan working on something similar, see https://wiki.ubuntu.com/DesktopTeam/Specs/Lucid/UserAccountManagement


Matthias has been putting together a prototype implementation of the original design. Tarballs can be found [http://mclasen.fedorapeople.org/accounts/ here]. Git repositories
Matthias has been putting together a prototype implementation of the original design. Tarballs and test packages can be found [http://mclasen.fedorapeople.org/accounts/ here]. ''Packages are now available in the F13 updates-testing repository.'' Git repositories are here:
are here:
* ssh://git.freedesktop.org/git/accountsservice ([http://cgit.freedesktop.org/accountsservice/ browse repo])
* ssh://git.freedesktop.org/git/accountsservice
* ssh://git.gnome.org/accounts-dialog ([http://git.gnome.org/browse/accounts-dialog/ browse repo])
* ssh://git.gnome.org/git/accounts-dialog
The code currently supports editing user information only, not groups. Login options are written back to /etc/gdm/custom.conf and GConf. The dialog uses the apg utility to generate (somewhat) memorable passwords. The D-Bus service uses the useradd, userdel and usermod tools to do changes, and per-user files in /var/lib/AccountsService to store non-passwd user data, such as password hints and user photos.
The code currently supports editing user information only, not groups. The dialog has the UI for login options, but it doesn't do anything because gdm lacks the necessary API. The dialog uses the apg utility to generate (somewhat) memorable passwords. The D-Bus service uses the useradd, userdel
 
and usermod tools to do changes, and per-user files in /var/lib/AccountsService to store non-passwd user data, such as password hints and user photos.
Work on a gdm patch to get user data from the accounts-service has
[http://bugzilla.gnome.org/show_bug.cgi?id=610179 mostly finished] and been built in F-13 branch, but still needs to get committed upstream.
 
The accountsservice and accountsdialog packages have been built in rawhide and F13.


Next steps:
Next steps:
* proper project infrastructure
* proper project infrastructure
* packages
* integration: make e.g. evolution, clock applet pick up user data from the service
* implement login options api in gdm
* integration: make e.g. evolution, clock applet, gdm pick up user data from the service


== Detailed Description ==
== Detailed Description ==
Line 50: Line 51:
* help with upstream acceptance
* help with upstream acceptance


A very rough sketch of the required API could look like this:
A very rough sketch of the required API could look like this (the + marks API currently implemented in the accounts service):
* list cached users
* list cached users
* get user by uid
* get user by uid (+)
* get user by name
* get user by name (+)
* list groups
* list groups  
* get group by gid
* get group by gid
* get group by name
* get group by name
* create user
* create user (+)
* delete user
* delete user (+)
* create group
* create group
* delete group
* delete group
Line 65: Line 66:
* list groups for user
* list groups for user
* list users for group
* list users for group
* user attributes: uid, name, real name, display name, home dir, shell, login frequency, locale, keyboard, email, icon, password hint, role
* user attributes: uid, name, real name, display name, home dir, shell, login frequency, locale, keyboard, email, icon, password hint, role (+)
* group attributes: gid, name
* group attributes: gid, name


Some of these will be privileged operations. Users will normally be allowed to set their own 'personal' data like real name, locale, keyboard, email, icon, password hint. Some of the attributes may be read-only, like uid and gid.
Some of these will be privileged operations. Users will normally be allowed to set their own 'personal' data like real name, locale, keyboard, email, icon, password hint. Some of the attributes may be read-only, like uid and gid.


Listing cached users is named that way to indicate that this is not meant to be a sync call to get a list of all users, which could be prohibitively expensive and slow in a networked scenario with a large directory service. Instead, the intention is to return a subset of users that has some relevance to the local system, e.g. only users that have logged into the local system within some timeframe. When the service gets reimplemented on top of InfoPipe, it may be advised to add a separate function to query users async and optain the results incrementally.
Listing cached users is named that way to indicate that this is not meant to be a sync call to get a list of all users, which could be prohibitively expensive and slow in a networked scenario with a large directory service. Instead, the intention is to return a subset of users that has some relevance to the local system, e.g. only users that have logged into the local system within some timeframe. When the service gets reimplemented on top of InfoPipe, it may be advised to add a separate function to query users asynchronously and obtain the results incrementally.


== Benefit to Fedora ==
== Benefit to Fedora ==
Line 78: Line 79:
== Scope ==
== Scope ==
* A dbus service providing user data needs to be written.
* A dbus service providing user data needs to be written.
* The service needs to be packaged for Fedora. [http://bugzilla.redhat.com/show_bug.cgi?id=560178 Review]
* The dialog itself needs to be written.
* The dialog itself needs to be written.
* The dialog needs to be packaged for Fedora. [http://bugzilla.redhat.com/show_bug.cgi?id=560179 Review]
* Several desktop components should be modified to use the service as well, the most prominent one is gdm, followed by applications that maintain user-related data, such as evolution or empathy
* Several desktop components should be modified to use the service as well, the most prominent one is gdm, followed by applications that maintain user-related data, such as evolution or empathy
* gdm needs to be modified to support setting passwords at first login, password hints, and disabled accounts
* gdm needs to be modified to support setting passwords at first login, password hints, and disabled accounts
Line 85: Line 88:


== How To Test ==
== How To Test ==
# Install the 'accountsdialog' package.
<!-- Note: Not currently obsoleting s-c-user or gnome-about-me
# Verify that gnome-about-me ('About me') and system-config-user ('Users and Groups') have been replaced by a single new menuitem ('Account management' or similar).
# Verify that gnome-about-me ('About me') and system-config-user ('Users and Groups') have been replaced by a single new menuitem ('Account management' or similar).
-->
# Verify that a new 'Users' item (or similar) has been added to the Administration menu (System->Administration in GNOME)
# Open the user account dialog. It should show you your own account data. Verify that you are able to change your own settings, such as user name or password. Verify that changing your account type requires privileges.
# Open the user account dialog. It should show you your own account data. Verify that you are able to change your own settings, such as user name or password. Verify that changing your account type requires privileges.
# Create a new account with the 'Add' button. Verify that this action requires privileges.
# Create a new account with the 'Add' button. Verify that this action requires privileges.
# Test that the various password generation policies work as  intended (ie 'Random password' should generate something that looks random, and 'Memorable password' should generate something memorable)
# Test that the password generation works. The 'Try again' button should generate a new batch of password proposals
# Verify that selecing 'Choose password at next login' has the desired effect at the next login
# Verify that selecting 'Choose password at next login' has the desired effect at the next login
# Verify that 'Disable this account' has the desired effect
# Verify that 'Disable this account' has the desired effect
# Verify that password hints are displayed when necessary on the login screen
# Verify that password hints are displayed when necessary on the login screen
Line 99: Line 106:
Users will have a single place to edit their account data and similar user-related data.
Users will have a single place to edit their account data and similar user-related data.


[[Image:Screenshot-Overview.png|frame|none|Overview]]
<gallery>
[[Image:Screenshot-Set-Password.png|frame|none|Setting a password]]
Image:Screenshot-Overview.png|Overview
[[Image:Screenshot-Generate-Password.png|frame|none|Generating a password]]
Image:Screenshot-Set-Password.png|Setting a password
[[Image:Screenshot-Language.png|frame|none|Setting the users language]]
Image:Screenshot-Generate-Password.png|Generating a password
[[Image:Screenshot-Photo-Gallery.png|frame|left|The icon selection popup]][[Image:Screenshot-Photo-Crop.png|frame|right|Webcam capture and cropping]]
Image:Screenshot-Language.png|Setting the users language
[[Image:Screenshot-Login-Options.png|frame|none|Login options]]
Image:Screenshot-Photo-Gallery.png|The icon selection popup
Image:Screenshot-Photo-Crop.png|Webcam capture and cropping
Image:Screenshot-Login-Options.png|Login options
</gallery>


TBD: fingerprint screenshots
TBD: fingerprint screenshots
Line 116: Line 126:
== Contingency Plan ==
== Contingency Plan ==
Stay with the current set of tools.
Stay with the current set of tools.
Alternatively, if the accounts-dialog lacks some important feature, we can include it but still ship the current tools.


== Documentation ==
== Documentation ==
Line 121: Line 133:


== Release Notes ==
== Release Notes ==
Fedora 13 includes a new user account dialog. It lets you create and modify user accounts and setup basic user information such as privileges, email addresses, user photo, etc. The new dialog supersedes functionality that was previously available in a variety of tools, such as system-config-user, gnome-about-me, gdmsetup and polkit-gnome-authorization, and makes it available in one place.
Fedora 13 includes a new user account dialog. It lets you create and modify user accounts and setup basic user information such as privileges, email addresses, user photo, etc. The new dialog supersedes functionality that was previously available in a variety of tools, such as system-config-user, gnome-about-me, gdmsetup and polkit-gnome-authorization, and makes it available in one place. Note that system-config-users and gnome-about-me are still available in Fedora 13.
 
To try the new user account dialog, install it with
 
yum install accountsdialog


== Comments and Discussion ==
== Comments and Discussion ==

Latest revision as of 20:13, 30 March 2010

User Account Dialog

Summary

A new user account dialog tool to create new users and edit user-related information in single-user systems or small deployments.

Owner

Current status

  • Targeted release: Fedora 13
  • Last updated: 2010-03-30
  • Percentage of completion: 100%

We have lots of (somewhat dated) design and scoping work that was done in Spring 2008: http://people.redhat.com/mclasen/user-account3.pdf.bz2. Here are some more sketches from back then: http://fedoraproject.org/wiki/Features/ImprovedUserManagementUI. Glade files for some of the mockups are here: http://people.fedoraproject.org/~mccann/design/user_accounts/. Earlier discussion around this idea happened here: https://www.redhat.com/archives/fedora-desktop-list/2008-May/msg00006.html

Ubuntu seem to be plan working on something similar, see https://wiki.ubuntu.com/DesktopTeam/Specs/Lucid/UserAccountManagement

Matthias has been putting together a prototype implementation of the original design. Tarballs and test packages can be found here. Packages are now available in the F13 updates-testing repository. Git repositories are here:

The code currently supports editing user information only, not groups. Login options are written back to /etc/gdm/custom.conf and GConf. The dialog uses the apg utility to generate (somewhat) memorable passwords. The D-Bus service uses the useradd, userdel and usermod tools to do changes, and per-user files in /var/lib/AccountsService to store non-passwd user data, such as password hints and user photos.

Work on a gdm patch to get user data from the accounts-service has mostly finished and been built in F-13 branch, but still needs to get committed upstream.

The accountsservice and accountsdialog packages have been built in rawhide and F13.

Next steps:

  • proper project infrastructure
  • integration: make e.g. evolution, clock applet pick up user data from the service

Detailed Description

The goal of this feature is create a single tool that allows to create new users and edit user-related information in single-user systems or small deployments. Big deployments and enterprise-level systems are not a target (we think those are better-served with a web interface for their directory server...).

The tool will (at least partially) replace the functionality of several existing components, such as system-config-users, gnome-about-me, the former gdmsetup, firstboot, the former polkit-gnome-authorization...

Use cases that we hope to cover are:

  • Creating the first user when the system boots for the first time
  • Editing your own account data
  • User account maintenance
  • Configuring the login screen
  • Temporary access to the system (guest account)

The dialog will rely on a system bus service to access and store user and group data. Longer-term, the hope is that SSSDs InfoPipe can serve as the backend for this. In the short term, we need a standalone implementation, which will

  • be good enough for the single-user and local scenarios
  • avoid blocking on InfoPipe
  • allow experiments with the API
  • help with upstream acceptance

A very rough sketch of the required API could look like this (the + marks API currently implemented in the accounts service):

  • list cached users
  • get user by uid (+)
  • get user by name (+)
  • list groups
  • get group by gid
  • get group by name
  • create user (+)
  • delete user (+)
  • create group
  • delete group
  • add user to group
  • remove user from group
  • list groups for user
  • list users for group
  • user attributes: uid, name, real name, display name, home dir, shell, login frequency, locale, keyboard, email, icon, password hint, role (+)
  • group attributes: gid, name

Some of these will be privileged operations. Users will normally be allowed to set their own 'personal' data like real name, locale, keyboard, email, icon, password hint. Some of the attributes may be read-only, like uid and gid.

Listing cached users is named that way to indicate that this is not meant to be a sync call to get a list of all users, which could be prohibitively expensive and slow in a networked scenario with a large directory service. Instead, the intention is to return a subset of users that has some relevance to the local system, e.g. only users that have logged into the local system within some timeframe. When the service gets reimplemented on top of InfoPipe, it may be advised to add a separate function to query users asynchronously and obtain the results incrementally.

Benefit to Fedora

A user account dialog has been missing for a long time. It will make the Fedora Desktop more complete and narrow the gap to other operating systems.

Scope

  • A dbus service providing user data needs to be written.
  • The service needs to be packaged for Fedora. Review
  • The dialog itself needs to be written.
  • The dialog needs to be packaged for Fedora. Review
  • Several desktop components should be modified to use the service as well, the most prominent one is gdm, followed by applications that maintain user-related data, such as evolution or empathy
  • gdm needs to be modified to support setting passwords at first login, password hints, and disabled accounts

Note that this page describes the changes in the desktop spin related to this feature. Other spins, such as the KDE or Xfce spins, can of course use the DBus service in their own user management tool or just continue to use system-config-user. If people are willing to work on this for other spins, the scope of the feature can be extended.

How To Test

  1. Install the 'accountsdialog' package.
  2. Verify that a new 'Users' item (or similar) has been added to the Administration menu (System->Administration in GNOME)
  3. Open the user account dialog. It should show you your own account data. Verify that you are able to change your own settings, such as user name or password. Verify that changing your account type requires privileges.
  4. Create a new account with the 'Add' button. Verify that this action requires privileges.
  5. Test that the password generation works. The 'Try again' button should generate a new batch of password proposals
  6. Verify that selecting 'Choose password at next login' has the desired effect at the next login
  7. Verify that 'Disable this account' has the desired effect
  8. Verify that password hints are displayed when necessary on the login screen
  9. Delete an account with the 'Remove' button. Verify that this action requires privileges.
  10. On the 'Login options' screen, enable autologin for your account (this requires privileges). Verify that you are automatically logged in after the next reboot
  11. Verify that changes to your account data (such as the icon or the user name) are reflected in the user switcher applet and in applications like evolution or emphathy)

User Experience

Users will have a single place to edit their account data and similar user-related data.

TBD: fingerprint screenshots

Dependencies

  • SSSD: The DBus service would ideally rely on SSSD for most of its data storage needs. If SSSD is not ready or does not provide what we need, we can temporarily use our own data storage.
  • PolicyKit: We want the dialog to be able to assign privileges/roles to users, for which we will rely on PolicyKit. PolicyKit 1.0 in F12 already provides the necessary framework for group-based policies (see the polkit-desktop-policy package), but minor adjustments might be necessary.
  • gdm: We want the dialog to be able to configure certain aspects of the login, e.g. autologin. gdm needs to provide some interface for this.
  • The dialog (partially or fully) supersedes the functionality of several existing components: system-config-users, gnome-about-me, the former gdmsetup, firstboot. We will want to avoid shipping the superseded components in the desktop spin, which might require some dependency surgery (e.g. currently anaconda pulls in system-config-users).

Contingency Plan

Stay with the current set of tools.

Alternatively, if the accounts-dialog lacks some important feature, we can include it but still ship the current tools.

Documentation

None yet.

Release Notes

Fedora 13 includes a new user account dialog. It lets you create and modify user accounts and setup basic user information such as privileges, email addresses, user photo, etc. The new dialog supersedes functionality that was previously available in a variety of tools, such as system-config-user, gnome-about-me, gdmsetup and polkit-gnome-authorization, and makes it available in one place. Note that system-config-users and gnome-about-me are still available in Fedora 13.

To try the new user account dialog, install it with

yum install accountsdialog

Comments and Discussion