All users of gnome-screensaver are advised to upgrade to this updated package, which fixes this bug. BZ Previously, gnome-screensaver's PAM configuration file was not marked as a configuration file in the gnome-screensaver spec file, and thus the configuration file was overwritten when updating the gnome-screensaver package.
Therefore, after the screen had been locked, users could not log into the system by using some of the previously specified authentication methods, or when users successfully logged in, automatic re-authentication with some applications could fail. With this update, the spec file has been corrected, and the pre-existing gnome-screensaver's PAM configuration file is now preserved when the package is updated so authentication problems no longer occur.
Why doesn't my screen lock when I'm logged in as root? I'm developing an application that has a fullscreen mode. Is there a way that I can disable the screensaver? I'm a systems administrator. How can I set policies for all users of my system? Is there a way to perform actions when the screensaver activates or deactivates? Or when the session becomes idle? How can I remove some themes from the list of themes shown in the preferences? Something has gone wrong. What can I do?
Can I embed an on-screen keyboard for use with mobile devices? I want to write a screensaver theme, how do I do that? Why gnome-screensaver, what happened to xscreensaver? It is designed to integrate well with the desktop and provide a control interface that is desktop neutral. It simplifies and streamlines the experience for the user and provides more capability for the system administrator and vendor.
It maintains a keyboard grab on the toplevel window at all times. This way there is no transfer of grabs to cause a race condition. The actual code paths through these libraries are quite small and very well tested. Actually, that seems to no longer be the case in GNOME3, after commit 76d2c9ff6acf4a98bfaa62fafe14e89fe gnome-screensaver only seems to support blanking. Xscreensaver XML configuration files can be converted into. We are trying to take a different approach.
A gnome-screensaver theme is not directly equivalent to the xscreensaver concept of a "hack". Each gnome-screensaver theme is a combination of a "hack" or theme engine and a set of options. This is quite a different design.
So, perhaps, a better question is how does one create a new theme for a pre-existing theme engine? For that please see the related section in this FAQ. So, why use a design that separates the theme from the theme engine? There are many reasons for this approach. I'll try to explain some of them. There are advantages for the user. It demands that themes simply work and that the defaults make sense.
And in the case where no one set of defaults will work it is now possible to simply provide a related theme of a different name. In many cases it makes sense to have multiple themes for the same theme engine. Take for example the slideshow theme engine. Rather than have one slideshow theme which you can configure to look in certain places for images it is now possible to have many slideshow themes - each with a different focus.
Or even install new ones! This may even create a market for new or enhanced themes. I can imagine that such demand will quickly be satisfied by the many third party theme sites such as art.
There are also many advantages for the parent, system administrator, or system distributor. Used to describe the software package as a whole. Greeter - The graphical login window provided by gnome-shell. Xserver - An implementation of the X Window System. For example the Xorg Xserver provided by the X. Paths that start with a word in angle brackets are relative to the installation prefix.
Note that GDM is configurable, and many configuration settings have an impact on security. Issues to be aware of are highlighted in this document. Please note that some Operating Systems configure GDM to behave differently than the default values as described in this document.
If GDM does not seem to behave as documented, then check to see if any related configuration may be different than described here. This list is archived, and is a good resource to check to seek answers to common questions. GDM 2. However, the codebase was completely rewritten for GDM 2. 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.
These features were not added back during the 2. GDM is responsible for managing displays on the system. This includes authenticating users, starting the user session, and terminating the user session. GDM is configurable and the ways it can be configured are described in the "Configuring GDM" section of this document.
GDM is also accessible for users with disabilities. GDM provides the ability to manage the main console display, and displays launched via VT. Regardless of the display type, GDM will do the following when it manages the display. It will start an Xserver process, then run the Init script as the root user, and start the greeter program on the display.
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 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.
The smartcard extension can be enabled or disabled via the org. Likewise, the fingerprint extension can be enabled or disabled via the org. 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. 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. After authenticating a user, the daemon runs the PostLogin script as root, then runs the PreSession script as root. After running these scripts, the user session is started.
When the user exits their session, the PostSession script is run as root. These scripts are provided as hooks for distributions and end-users to customise how sessions are managed. The PreSession script is called after session initialisation. 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. Note that keyboard layout features are only available on systems that support libxklavier. 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. On some Operating Systems, it is necessary to make sure that the GDM user is a member of the "audio" group for AT programs that require audio output such as text-to-speech to be functional.
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. When disabled, users must type their complete username by hand. The face browser in GDM 2. 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.
Face icons placed in the global face directory must be readable to the GDM user. 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.
When the browser is turned on, valid usernames on the computer are exposed for everyone to see. 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. A lot of the protocol parameters, handshaking timeouts, etc.
The default configuration should work reasonably on most systems. 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. 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.
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. GDM allows multiple users to be logged in at the same time. 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. For security reasons a dedicated user and group ID are recommended for proper operation. This user and group are normally "gdm" on most systems, but can be configured to any user or group.
This user and group should have limited privileges. Any user who gains access to an Xauth key can snoop on and control running GUI programs running in the associated session or perform a denial-of-service attack on it. It is important to ensure that the system is configured properly so that only the "gdm" user has access to these files and that it is not easy to login to this account.
For example, the account should be setup to not have a password or allow non-root users to login to the account.
However, some features of GDM may be disabled if it is unable to write state information to GConf configuration.
PAM stands for Pluggable Authentication Module, and is used by most programs that request authentication on your computer. It allows the administrator to configure specific authentication behavior for different login programs such as SSH, login GUI, screensaver, etc. PAM is complicated and highly configurable, and this documentation does not intend to explain this in detail.
It is expected that a person needing to do PAM configuration would need to do further reading of PAM documentation to understand how to configure PAM and to understand terms used in this section. PAM configuration has different, but similar, interfaces on different Operating Systems, so check the pam. Be sure you read the PAM documentation and are comfortable with the security implications of any changes you intend to make to your configuration.
These services may not be defined in your pam. On most systems this should work fine. However, the automatic login feature may not work if the gdm-autologin service is not defined.
This allows the system administrator to add any scripting to the login process either before or after PAM initialises the session. If you wish to make GDM work with other types of authentication mechanisms such as a fingerprint or SmartCard reader , then you should implement this by using a PAM service module for the desired authentication type rather than by trying to modify the GDM code directly.
Refer to the PAM documentation on your system. PAM does have some limitations regarding being able to work with multiple types of authentication at the same time, like supporting the ability to accept either SmartCard and the ability to type the username and password into the login program. There are techniques that are used to make this work, and it is best to research how this problem is commonly solved when setting up such a configuration.
If automatic login does not work on a system, check to see if the "gdm-autologin" PAM stack is defined in the PAM configuration. The above setup will cause no lastlog entry to be generated. If a lastlog entry is desired, then use the following for the session:. If the computer is used by several people, which makes automatic login unsuitable, you may want to allow some users to log in without entering their password.
This feature can be enabled as a per-user option in the users-admin tool from the gnome-system-tools; it is achieved by checking that the user is member a Unix group called "nopasswdlogin" before asking for a password. For this to work, the PAM configuration file for the "gdm" service must include a line such as:.
The utmp database contains user access and accounting information that is accessed by commands such as finger , last , login , and who. The wtmp database contains the history of user access and accounting information for the utmp database. Refer to the utmp and wtmp man pages on your system for more information. These files are used to store and share a "password" between X clients and the Xserver.
This "password" is unique for each session logged in, so users from one session can't snoop on users from another. Normally little is gained from the other schemes, and no effort has been made to implement them so far. If snooping is possible, then an attacker could simply snoop your authentication password as you log in, regardless of the authentication scheme being used.
If snooping is possible and undesirable, then you should use ssh for tunneling an X connection rather then using XDMCP. Even though your display is protected by cookies, XEvents and keystrokes typed when entering passwords will still go over the network in clear text. It is trivial to capture these. XDMCP is primarily useful for running thin clients such as in terminal labs. Those thin clients will only ever need the network to access the server, and so it seems like the best security policy to have those thin clients on a separate network that cannot be accessed by the outside world, and can only connect to the server.
0コメント