It IT/Releases/13/Features/UserAccountDialog

Finestra di dialog per account utente

Sommario

Un nuovo strumento di dialogo per creare utenti e modificare informazioni sugli utenti per sistemi mono-utenti o piccoli sistemi.

Progettista

• Nome: Matthias Clasen, Ray Strode
• Email: mclasen@redhat.com, rstrode@redhat.com

Stato corrente

• Release: Fedora 13
• Ultimo aggiornamento: 21-01-2010
• Percentuale di completamento: 40%

Il progetto nasce da idee e osservazioni che risalgono alla primavera del 2008. Di seguito si riportano le idee così come si vennero formando:

http://people.redhat.com/mclasen/user-account3.pdf.bz2
http://fedoraproject.org/wiki/Features/ImprovedUserManagementUI: alcuni schizzi delle idee da concretizzare
http://people.fedoraproject.org/~mccann/design/user_accounts/: alcuni file Glade
https://www.redhat.com/archives/fedora-desktop-list/2008-May/msg00006.html: precedenti discussioni sul progetto

Anche Ubuntu sembra stia progettando qualcosa di simile, vedi
https://wiki.ubuntu.com/DesktopTeam/Specs/Lucid/UserAccountManagement

Matthias sta implementando un prototipo del progetto originale. I tarballs si trovano quì. I repositorie Git sono questi:

• ssh://git.freedesktop.org/git/accountsservice
• ssh://git.gnome.org/git/accounts-dialog

Il codice, allo stato attuale, consente di modificare solo le informazioni degli utenti, non dei gruppi. La finestra di dialogo ha un'interfaccia utente per impostare le opzioni di login, ma per ora è inattiva in quanto la gdm è priva delle necessarie API. La finestra impiega l'utility apg per generare password quasi memorabili. Il servizio D-Bus usa useradd, userdel e usermod per le modifiche, e i file in /var/lib/AccountsService per conservare i dati utente che non richiedono password, come suggerimenti per buone password o foto degli utenti.

Prossimi obiettivi:

• trovare la collocazione all'interno dell'infrastruttura di progetto
• realizzare i pacchetti
• implementare le opzioni di login in gdm con le necessarie API
• integrazione: consentire p.e. ad evolution, all'applet orologio, o a gdm di recuperare i dati utente dal servizio

Descrizione Dettagliata

L'obbiettivo di questo progetto è di creare un singolo strumento capace di creare nuovi utenti e di modificare le informazioni relative agli utenti in sistemi mono-utenti o piccoli sistemi. I sistemi più grandi ed enterprise non sono un obbietivo presente (si ritiene che questi siano meglio gestibili attarverso un interfacce web del server ...).

Il dipositivo sostituirà (almeno in parte) le funzionalità di diversi componenti esistenti, come system-config-users, gnome-about-me, gdmsetup, firstboot, e polkit-gnome-authorization, tra gli altri.

Le funzionalità implementate dovranno consentire di:

• Creare il primo utente quando il sistema si avvia per la prima volta
• Inserire le proprie informazioni d'accesso
• Consentire di gestire gli account
• Configurare la schernata di login
• Regolare il tempo d'accesso al sistema (guest account)

La finestra di dialogo si baserà su un servizio di bus di sistema per accedere e salvare i dati degli utenti e dei gruppi. In futuro, si spera di poter impiegare le InfoPipe SSSD come supporto base. Per ora, occorre realizzare una implemetazione indipendente, che

• sia sufficiente per scenari mono-utenti e locali
• eviti il blocco delle InfoPipe
• consenta la sperimentazione delle API
• sia in accordo con le richieste a monte

Una lista delle specifiche API, potrebbe essere grosso modo la seguente:

• elencare gli utenti cached
• recuperare l'utente dall'uid
• recuperare l'utente dal nome
• elencare i gruppi
• recuperare il gruppo dal gid
• recuperare il gruppo dal nome
• creare un utente
• eliminare un utente
• creare un gruppo
• eliminare un gruppo
• aggiungere un utente a un gruppo
• eliminare un utente da un gruppo
• elencare i gruppi per utente
• elencare gli utenti per grupppo
• specificare/modficare gli attributi utente: uid, nome, nome reale, nome visualizzato, directory home , shell, frequenza di accesso, località, tastiera, email, icona, suggerimento password, ruolo
• specificare gli attributi di gruppo: gid, nome

Alcune di queste, sono operazioni privilegiate. Gli utenti, di solito saranno autorizzati a impostare solo i propri dati personali, come il nome reale, la località, la tastiera, l'email, l'icona, il suggerimento per password. Altri saranno accessibili solo in lettura come uid e gid.

Elencare gli utenti cached significa che per ottenere l'elenco di tutti gli utenti non si esegue una chiamata di sistema sincrona, che potrebbe risultare estremamente costosa e lenta in uno scenario di rete con un directory service piuttosto grande. Invece, si intende restituire soltanto un insieme ristretto di utenti che hanno una certa rilevanza nel sistema locale, p.e. quegli utenti che hanno avviato una sessione locale in un certo intervallo di tempo. Quando poi il servizio sarà reimplementato su basi InfoPipe, si può suggerire di inserire una funzione separata per recuperare gli utenti in modo asincrono ed ottenere i risultati in modo incrementale.

Vantaggi per Fedora

Una finestra di dialogo mancava da molto tempo. Tale finestra renderà il desktop Fedora più completo e ridurrà il gap dagli altri S.O.

Scope

• A dbus service providing user data needs to be written.
• The dialog itself needs to be written.
• 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. 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).
2. 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.
3. Create a new account with the 'Add' button. Verify that this action requires privileges.
4. 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)
5. Verify that selecing 'Choose password at next login' has the desired effect at the next login
6. Verify that 'Disable this account' has the desired effect
7. Verify that password hints are displayed when necessary on the login screen
8. Delete an account with the 'Remove' button. Verify that this action requires privileges.
9. On the 'Login options' screen, enable autologin for your account (this requires privileges). Verify that you are automatically logged in after the next reboot
10. 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.

Overview

Setting a password

Generating a password

Setting the users language

The icon selection popup

Webcam capture and cropping

Login options

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.

Comments and Discussion

• See Talk:Features/UserAccountDialog