See the Port option for more information. The service name is gdm. Please note that XDMCP is not a particularly secure protocol and that it is a good idea to block UDP port on your firewall unless you really need it.
To avoid denial of service attacks, GDM has fixed size queue of pending connections. Only MaxPending displays can start at the same time. It only limits the number of displays initiating a connection simultaneously.
Determines the maximum number of remote display connections which will be managed simultaneously. If no response is received within MaxWait seconds, GDM will declare the display dead and erase it from the pending queue freeing up the slot for other displays. The MaxWaitIndirect parameter determines the maximum number of seconds between the time where a display requests a chooser and completion of protocol negotiation.
If the timeout is exceeded, GDM will remove the display from the pending list freeing up the slot for other displays. Don't change this unless you know what you're doing. Specifies the maximum icon width in pixels that the face browser will display. Icons larger than this will be scaled. Specifies the maximum icon height in pixels that the face browser will display. Set to 1 to enable the face browser. The image must be in an Imlib supported format and the file must be readable for the gdm user.
Comma-separated list of usernames to exclude from the face browser. The excluded users will still be able to log in. Systemwide directory for face files.
The sysadmin can place icons for users here without touching their homedirs. Faces are named after their users' logins. No image format extension should be specified.
The face images must be stored in Imlib supported formats and they must be readable for the GDM user. A user's own icon file will always take precedence over the sysadmin provided one.
Icon to use for gdmlogin when it's in the iconified state. The image must be in an Imlib supported format and it must be readable for the GDM user. If no file is specified the iconify feature is disabled. File in GNU locale format with entries for all supported languages on the system.
Image file to display in the logo box. The file must be in an Imlib supported format and it must be readable by the GDM user. If no file is specified the logo feature is disabled. Controls which text to display next to the logo image in the greeter. The following control chars are supported:. File name for the default host icon. This image will be displayed if no icon is specified for a given host.
The file must be in an Imlib supported format and it must be readable for the GDM user. Repository for host icon files. The sysadmin can place icons for remote hosts here and they will appear in gdmchooser. The file name must match the fully qualified name FQDN for the host. The icons must be stored in Imlib supported formats and they must be readable to the gdm user. Control section for local X servers. Each line indicates the local display number and the command that needs to be run to start the X server s.
Xauth :n ", where n is the display number. Petersen mkp mkp. Table of Contents Terms and conventions used in this book 1. Overview 1.
Introduction 1. The GDM Daemon 1. XDMCP 1. The Greeter 1. Text entry 1. The Menu 1. The face browser 1. The Logo 2. The Configuration Directory 2. The Script Directories 2. The Face Browser is enabled in the Graphical greeter by selecting a theme that includes the Face Browser, such as happygnome-list.
They will not be displayed regardless of the settings for Include and Exclude. Users should be separated by commas. Excluded users will still be able to log in, but will have to type their username.
By setting IncludeAll to true, the password file will be scanned and all users will be displayed except users excluded via the Exclude setting and user ID's less than MinimalUID.
Scanning the password file can be slow on systems with large numbers of users and this feature should not be used in such environments. The setting of IncludeAll does nothing if Include is set to a non-empty value. Likely you want to use the one shipped with GDM and edit it. It is not a standard locale.
None of these is available if this is off. They can be turned off individually however. If this is shown, GDM can drop into chooser mode which will run the xdmcp chooser locally and allow the user to connect to some remote host. Not for true multihead, currently only works for Xinerama. Perhaps something like an xscreensaver hack or some such. These are much MUCH nicer focus for xterm for example and more failsafe then those supplied by scripts so distros should use this rather then just running an xterm from a script.
This is standard for instance in console, xdm and ssh. Circles is the standard shipped theme. Otherwise use GraphicalTheme and specify just one theme. The purpose is to provide a hook where files used after login can be preloaded to speed performance for the user. The program will only be called once only, the first time a greeter is displayed. The gdmprefetch command may be used. This utility will load any libraries passed in on the command line, or if the argument starts with a " " character, it will process the file assuming it is an ASCII file containing a list of libraries, one per line, and load each library in the file.
You can use this to reach hosts that broadcast cannot reach. It is hardcoded here and will be replaced when officially registered xdmcp multicast address of TBD will be available.
It is not recommended to turn this on for normal use, but it can be useful to determine the cause when GDM is not working properly. This includes output about key events, mouse button events, and pointer motion events.
This is useful for figuring out the cause of why the gesture listeners may not be working, but is too verbose for general debug. The first word in the value corresponds to an X server definition in the "X Server Definitions" section of the configuration file. If the device argument is not defined, then GDM will use the default setting for attached displays defined in the UtmpLineAttached configuration option. Values can be any integer value accepted by the setpriority C library function normally between and 20 with 0 being the default.
For highly interactive applications, -5 yields good responsiveness. The default value is 0 and the setpriority function is not called if the value is 0. You can make a terminal server flexible, but not with an indirect query. If you need flexible indirect query server, then you must get rid of the -terminate and the only way to kill the flexible server will then be by Ctrl-Alt-Backspace.
This is the only way to make a flexible chooser server that behaves nicely. When the user chooses a machine they will get this same server but run with "-terminate -query hostname". Each of the commands can be defined by the seven parameters listed below. In each of the descriptions of the parameters N can take on any values between 0 and 9, i.
The numbers can have gaps as long as they fit within predefined set of 10, and their placement order within this section and with respect to each other is not important. Custom command to run. Multiple commands may be specified separated by semicolons. GDM will use the first valid command.
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.
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.
The only point from which you need to access outside is the server. This type of set up should never use an unmanaged hub or other sniffable network. For example, to deny computers from. You may also need to add. See the hosts. GDM guards against denial of service attacks, but the X protocol is still inherently insecure and should only be used in controlled environments.
Also each remote connection takes up lots of resources, so it is much easier to do a denial of service attack via XDMCP than attacking a webserver. It is also wise to block all of the Xserver ports. Note that GDM will use display numbers 20 and higher for flexible on-demand servers.
GDM may be configured to use PolicyKit to allow the system administrator to control whether the login screen should provide the shutdown and restart buttons on the greeter screen. These buttons are controlled by the org.
Policy for these actions can be set up using the polkit-gnome-authorization tool, or the polkit-auth command line program. In this case the RBAC configuration is used to control whether the login screen should provide the shutdown and restart buttons on the greeter screen. For example, on Oracle Solaris, the "solaris. GDM includes support for publishing user login information with the user and login session accounting framework known as ConsoleKit.
ConsoleKit is able to keep track of all the users currently logged in. In this respect, it can be used as a replacement for the utmp or utmpx files that are available on most Unix-like Operating Systems. When GDM is about to create a new login process for a user it will call a privileged method of ConsoleKit in order to open a new session for this user. At this time GDM also provides ConsoleKit with information about this user session such as: the user ID, the X11 Display name that will be associated with the session, the host-name from which the session originates useful in the case of an XDMCP session , whether or not this session is attached, etc.
As the entity that initiates the user process, GDM is in a unique position to know about the user session and to be trusted to provide these bits of information. The use of this privileged method is restricted by the use of the D-Bus system message bus security policy. In case a user with an existing session has authenticated at GDM and requests to resume that existing session, GDM calls a privileged method of ConsoleKit to unlock that session.
The exact details of what happens when the session receives this unlock signal are undefined and session-specific. However, most sessions will unlock a screensaver in response. When the user chooses to log out, or if GDM or the session quit unexpectedly the user session will be unregistered from ConsoleKit. GDM has a number of configuration interfaces.
0コメント