Panoramica
- 2.1. Introduzione
- 2.2. Stabilità dell'interfaccia
- 2.3. Descrizione funzionale
- 2.4. Pannello greeter
- 2.5. Accesso universale
- 2.6. Il face browser di GDM
- 2.7. XDMCP
- 2.8. Logging
- 2.9. Fast User Switching
2.1. Introduzione
Lo GNOME Display Manager (GDM) è un display manager che implemente tutte le funzioni significative richieste per la gestione di display collegati e remoti. GDM è stato scritto da zero e non contiene alcun codice derivato da XDM o X Consortium.
Notare che GDM è configurabile e molte impostazioni di configurazione hanno un impatto sulla sicurezza. In questo documento, le problematiche di cui è bene essere a conoscenza sono messe in evidenza.
Notare che alcuni sistemi operativi configurano GDM per comportarsi diversamente dai valori predefiniti descritti in questo documento. Se GDM non dovesse comportarsi come qui documentato, controllare che ogni configurazione relativa non sia differente da quanto qui descritto.
For further information about GDM, refer to the project website at http://wiki.gnome.org/Projects/GDM.
Per discudere o fare domande su GDM, fare riferimento alla mailing list
. Tutti i messaggi sono archiviati e rappresentano un'ottima risorsa da controllare per trovare risposta a domande comuni. L'archivio della lista è disponibile presso http://mail.gnome.org/archives/gdm-list/ ed è presesnete una funziona ricerca per consultare i messaggi in base a parole chiave.Inviare le segnalazioni di bug o le richieste di miglioramenti su http://bugzilla.gnome.org.
2.2. Stabilità dell'interfaccia
GDM 2.20 and earlier supported stable configuration interfaces. However, the codebase was completely rewritten for GDM 2.22, and is not completely backward compatible with older releases. This is in part because things work differently, so some options just don't make sense, in part because some options never made sense, and in part because some functionality has not been reimplemented yet.
Le interfacce che continuano ad essere supportate in modo stabile includono gli script Init, PreSession, PostSession, PostLogin e Xsession. Alcune opzioni di configurazione del demone nel file <etc>/gdm/custom.conf continuano ad essere supportate. Sono infine ancora supportati il file ~/.dmrc e le posizioni delle immagini del "face browser".
GDM 2.20 and earlier supported the ability to manage multiple displays with separate graphics cards, such as used in terminal server environments, login in a window via a program like Xnest or Xephyr, the gdmsetup program, XML-based greeter themes, and the ability to run the XDMCP chooser from the login screen. These features were not added back during the 2.22 rewrite.
2.3. Descrizione funzionale
GDM è responsabile della gestione dei display sul sistema. Ciò include l'autenticazione degli utenti, l'avvio di sessioni utente e la terminazione di sessioni utente. GDM è configurabile nei modi descritti nella sezione «Configurare GDM» di questo documento. GDM risulta inoltre accessibile per utenti con disabilità.
GDM fornisce la possibilità di gestire il display di console principale e i display lanciati attraverso VT. Ciò risulta integrato con altri programmi, come l'applet «Cambia utente» e gnome-screensaver per poter gestire display multipli sulla console attraverso l'interfaccia Xserver Virtual Terminal (VT). È anche possibile gestire i display XDMCP.
Indipendentemente dal tipo di display, GDM esegue quanto di seguito indicato quando gestisce il display: avvia un processo Xserver, poi avvia lo script Init come utente root, infine avvia il programma greeter sul display.
The greeter program is run as the unprivileged "gdm" user/group. This user and group are described in the "Security" section of this document. The main functions of the greeter program are to provide a mechanism for selecting an account for log in and to drive the dialogue between the user and system when authenticating that account. The authentication process is driven by Pluggable Authentication Modules (PAM). The PAM modules determine what prompts (if any) are shown to the user to authenticate. On the average system, the greeter program will request a username and password for authentication. However some systems may be configured to use supplemental mechanisms such as a fingerprint or SmartCard readers. GDM can be configured to support these alternatives in parallel with greeter login extensions and the --enable-split-authentication ./configure option, or one at a time via system PAM configuration.
The smartcard extension can be enabled or disabled via the org.gnome.display-manager.extensions.smartcard.active gsettings key.
Likewise, the fingerprint extension can be enabled or disabled via the org.gnome.display-manager.extensions.fingerprint.active gsettings key.
GDM and PAM can be configured to not require any input, which will cause GDM to automatically log in and simply start a session, which can be useful for some environments, such as single user systems or kiosks.
In addition to authentication, the greeter program allows the user to select which session to start and which language to use. Sessions are defined by files that end in the .desktop suffix and more information about these files can be found in the "GDM User Session and Language Configuration" section of this document. By default, GDM is configured to display a face browser so the user can select their user account by clicking on an image instead of having to type their username. GDM keeps track of the user's default session and language in the user's ~/.dmrc and will use these defaults if the user did not pick a session or language in the login GUI.
Dopo aver autenticato un utente, il demone esegue lo script PostLogin come root, quindi lo script PreSession come root. Dopo l'esecuzione di questi script viene avviata la sessione utente. Quando l'utente termina la propria sessione, viene eseguito lo script PostSession come root. Tali script sono forniti come agganci per i distributori e gli utenti finali al fine di personalizzare la gestione delle sessioni. Per esempio, usando tali agganci è possibile impostare una macchina in modo da creare al volo la directory $HOME dell'utente e di eliminarla al temine della sessione. La differenza tra gli script PostLogin e PreSession risiede nel fatto che PostLogin è eseguito prima della chiamata pam_open_session, rendendolo così il posto adatto per ogni azione che debba essere eseguita prima dell'inizializzazione della sessione utente. Lo script PreSession è chiamato dopo l'inizializzazione della sessione.
2.4. Pannello greeter
The GDM greeter program displays a panel docked at the bottom of the screen which provides additional functionality. When a user is selected, the panel allows the user to select which session, language, and keyboard layout to use after logging in. The keyboard layout selector also changes the keyboard layout used when typing your password. The panel also contains an area for login services to leave status icons. Some example status icons include a battery icon for current battery usage, and an icon for enabling accessibility features. The greeter program also provides buttons which allow the user to shutdown or restart the system. It is possible to configure GDM to not provide the shutdown and restart buttons, if desired. GDM can also be configured via PolicyKit (or via RBAC on Oracle Solaris) to require the user have appropriate authorization before accepting the shutdown or restart request.
Note that keyboard layout features are only available on systems that support libxklavier.
2.5. Accesso universale
GDM supports "Accessible Login", allowing users to log into their desktop session even if they cannot easily use the screen, mouse, or keyboard in the usual way. Accessible Technology (AT) features such as an on-screen keyboard, screen reader, screen magnifier, and Xserver AccessX keyboard accessibility are available. It is also possible to enable large text or high contrast icons and controls, if needed. Refer to the "Accessibility Configuration" section of the document for more information how various accessibility features can be configured.
Su alcuni sistemi è necessario assicurarsi che l'utente GDM sia un membro del gruppo "audio" per quei programmi di tecnologia assistiva che richiedono una uscita audio (come testo-a-parlato).
2.6. Il face browser di GDM
The Face Browser is the interface which allows users to select their username by clicking on an image. This feature can be enabled or disabled via the org.gnome.login-screen disable-user-list GSettings key and is on by default. When disabled, users must type their complete username by hand. When enabled, it displays all local users which are available for login on the system (all user accounts defined in the /etc/passwd file that have a valid shell and sufficiently high UID) and remote users that have recently logged in. The face browser in GDM 2.20 and earlier would attempt to display all remote users, which caused performance problems in large, enterprise deployments.
The Face Browser is configured to display the users who log in most frequently at the top of the list. This helps to ensure that users who log in frequently can quickly find their login image.
The Face Browser supports "type-ahead search" which dynamically moves the face selection as the user types to the corresponding username in the list. This means that a user with a long username will only have to type the first few characters of the username before the correct item in the list gets selected.
The icons used by GDM can be installed globally by the sysadmin or can be located in the user's home directories. If installed globally they should be in the <share>/pixmaps/faces/ directory and the filename should be the name of the user. Face image files should be a standard image that GTK+ can read, such as PNG or JPEG. Face icons placed in the global face directory must be readable to the GDM user.
If there is no global icon for the user, GDM will look in the user's $HOME directory for the image file. GDM will first look for the user's face image in ~/.face. If not found, it will try ~/.face.icon. If still not found, it will use the value defined for "face/picture=" in the ~/.gnome2/gdm file.
If a user has no defined face image, GDM will use the "stock_person" icon defined in the current GTK+ theme. If no such image is defined, it will fallback to a generic face image.
Please note that loading and scaling face icons located in remote user home directories can be a very time-consuming task. Since it not practical to load images over NIS or NFS, GDM does not attempt to load face images from remote home directories.
When the browser is turned on, valid usernames on the computer are exposed for everyone to see. If XDMCP is enabled, then the usernames are exposed to remote users. This, of course, limits security somewhat since a malicious user does not need to guess valid usernames. In some very restrictive environments the face browser may not be appropriate.
2.7. XDMCP
The GDM daemon can be configured to listen for and manage X Display Manage Protocol (XDMCP) requests from remote displays. By default XDMCP support is turned off, but can be enabled if desired. If GDM is built with TCP Wrapper support, then the daemon will only grant access to hosts specified in the GDM service section in the TCP Wrappers configuration file.
GDM includes several measures making it more resistant to denial of service attacks on the XDMCP service. A lot of the protocol parameters, handshaking timeouts, etc. can be fine tuned. The default configuration should work reasonably on most systems.
GDM by default listens for XDMCP requests on the normal UDP port used for XDMCP, port 177, and will respond to QUERY and BROADCAST_QUERY requests by sending a WILLING packet to the originator.
GDM can also be configured to honor INDIRECT queries and present a host chooser to the remote display. GDM will remember the user's choice and forward subsequent requests to the chosen manager. GDM also supports an extension to the protocol which will make it forget the redirection once the user's connection succeeds. This extension is only supported if both daemons are GDM. It is transparent and will be ignored by XDM or other daemons that implement XDMCP.
If XDMCP seems to not be working, make sure that all machines are specified in /etc/hosts.
Refer to the "Security" section for information about security concerns when using XDMCP.
2.8. Logging
GDM uses syslog to log errors and status. It can also log debugging information, which can be useful for tracking down problems if GDM is not working properly. Debug output can be enabled by setting the debug/Enable key to "true" in the <etc>/gdm/custom.conf file.
Output from the various Xservers is stored in the GDM log directory, which is normally <var>/log/gdm/. Any Xserver messages are saved to a file associated with the display value, <display>.log.
The session output is piped through the GDM daemon to the ~/$XDG_CACHE_HOME/gdm/session.log file which usually expands to ~/.cache/gdm/session.log. The file is overwritten on each login, so logging out and logging back into the same user via GDM will cause any messages from the previous session to be lost.
Note that if GDM can not create this file for some reason, then a fallback file will be created named ~/$XDG_CACHE_HOME/gdm/session.log.XXXXXXXX where the XXXXXXXX are some random characters.
2.9. Fast User Switching
GDM allows multiple users to be logged in at the same time. After one user is logged in, additional users can log in via the User Switcher on the GNOME Panel, or from the "Switch User" button in Lock Screen dialog of GNOME Screensaver. The active session can be changed back and forth using the same mechanism. Note that some distributions may not add the User Switcher to the default panel configuration. It can be added using the panel context menu.
Note this feature is available on systems that support Virtual Terminals. This feature will not function if Virtual Terminals is not available.