Themes can be selected and new themes can be installed by running gdmsetup, or by setting the "GraphicalTheme" parameter in gdm. The location of themes is specified by the "GraphicalThemeDir" parameter. The look and feel of this greeter is controlled by the theme, so the user interface elements that are present might differ. The only item that must always be present is the text entry field, as described in the Standard Greeter section above. You can display a menu of avail- able actions by pressing the F10 key.

This can be useful if the theme does not provide certain buttons when you wish to perform a particu- lar action. Chooser The Chooser displays a list of local machines that accept XDMCP connections. The user can also specify a machine by entering its name directly. Once a machine is selected, a remote XDMCP session can be started. The Chooser can be launched on the console directly from the Standard or Graphical Greeter.

The chooser corresponds to the executable gdmchooser. XDMCP GDM can be configured to enable XDMCP so that users can log in remotely and launch a graphical chooser that allows a remote login session to be started. See the [xdmcp] section of the gdm. conf file. GDM grants access to the hosts specified in the GDM service section of your TCP Wrappers configuration file. GDM does not support remote display access control on systems without TCP Wrappers. GDM includes several measures that make GDM more resistant to denial-of-service attacks on the XDMCP service.

Several protocol parameters, handshaking timeouts, and so on can be fine-tuned. The default values should work for most systems, however. Do not change these values unless you know what you are doing. By default, GDM listens to UDP port , although this can be configured.

GDM can also be configured to honor INDIRECT queries and present a host chooser to the remote display. GDM remembers the user's choice and forwards subsequent requests to the chosen manager. GDM also supports an extension to the protocol which makes GDM forget the redirection once the user's connection succeeds. This extension is only supported if both daemons are GDM. This extension is transparent and is ignored by XDM or other daemons that implement XDMCP.

GDM only supports the MIT-MAGIC-COOKIE-1 authentication system. Because of this, the cookies are transmitted as clear text. Therefore, you should be careful about the network where you use this. That is, be careful about where your XDMCP connection is going.

Note that if snoop- ing is possible, an attacker could snoop your password as you log in, so a better XDMCP authentication would not help you much anyway. If snooping is possible and undesirable, you should use ssh for tunneling an X connection, rather then using GDM's XDMCP. Think of XDMCP as a sort of graphical telnet, with the same security issues. Controlling GDM You can control GDM behavior during runtime in several different ways. You can run certain commands, or you can talk to GDM using either a UNIX socket protocol, or a FIFO protocol.

You can control GDM behavior as follows: o To stop GDM, you can either send the TERM signal to the main daemon, or run the gdm-stop command. o To restart GDM, you can either send the HUP signal to the main daemon, or run the gdm-restart command. o To restart GDM but only after all users have logged out, you can either send the USR1 signal to the main daemon, or run the gdm-safe- restart command. The gdmflexiserver command can be used to communicate with the GDM daemon and to start new flexible on demand servers.

Configuration The gdm. conf file contains comments that explain each configuration parameter. Security GDM is best used with a dedicated user id and group id that GDM uses for graphical interfaces such as gdmgreeter, gdmlogin, and gdmchooser.

You can specify the name of this user and group in the [daemon] section of the gdm. The GDM user and group, which are normally just GDM, should not be a user or group of any particular privilege.

The reason for using the GDM user and group is to have the user interface run as a user without privileges, so that in the unlikely case that someone finds a weak- ness in the GUI, they cannot access root on the machine.

Note that the GDM user and group have some privileges that make them somewhat dangerous. They have access to the server authorization directory specified by the ServAuthDir parameter in gdm. conf , which contains all of the X server authorization files and other private information. The server authorization directory ServAuthDir is used for a host of random internal data, in addition to the X server authorization files, and the naming is really a relic of history.

The GDM daemon forces this directory to be owned by root:gdm with permissions of This means that only the root user and the GDM group have write access to this directory, but the GDM group cannot remove the root-owned files from this directory, such as the X server authorization files. By default, GDM does not trust the server authorization directory and treats it in the same way as a temporary directory with respect to creating files.

This means that someone breaking the GDM user cannot mount attacks by creating links in this directory. Similarly, the X server log directory is treated safely, but that directory should really be owned and writable only by the root user. Accessibility GDM supports "Accessible Login" to allow users to log in to their desktop session even if they cannot easily use the screen, mouse, or key- board in the usual way.

This also enables the user to change the visual appearance of the login UI before logging in, for example to use a higher-contrast color scheme for better visi- bility. GDM only supports accessibility with the Standard Greeter, so the "Greeter" parameter in gdm.

conf must be set to the Standard Greeter "gdmlogin". To enable Accessible Login, the system administrator must modify the default login configuration by manually modifying three human-readable configuration files, stored in gdm. conf, AccessKeyMouseEvents, and AccessDwellMouseEvents. To allow users to change the color and contrast scheme of the login dialog, set the "AllowThemeChange" parameter in gdm.

conf to "true". To restrict user changes of the visual appearance to a subset of available themes, the "GtkThemesToAllow" parameter in gdm. conf can be set to a list of acceptable themes separated by commas. conf must be uncommented and set to "true".

Also, the "GtkModulesList" parameter must be uncommented and set to "gail:atk-bridge:dwell- mouselistener:keymouselistener". System administrators might wish to load only the minimum subset of these modules that is required to support their user base. Depending on the end-user needs, it might not be necessary to load all of the GtkModules: o If a user needs the integrated Screen Reader and Magnifier, you must include "gail" and "atk-bridge".

o If a user needs a pointing device without buttons or switches, include "dwellmouselistener". Including all four modules is suitable for most system configurations. The Onscreen Keyboard can operate without gail and atk-bridge, but with a reduced feature set.

For optimum accessibility, we recommend including gail and atk-bridge. When "keymouselistener" or "dwellmouselistener" have been added to the GtkModules loaded by GDM, you can assign user actions to the launch- ing of specific assistive technologies. These gesture associations are contained in the files AccessKeyMouseEvents and AccessDwell- MouseEvents, respectively.

The gesture format is described in the two files. The AccessKeyMouseEvents file controls the keymouselistener Gesture Listener and is used to define key-press, mouse button, or XInput device sequences that can be used to launch programs needed for accessibility. The DwellKeyMouseEvents file controls the dwellmouselistener and supports gestures that involve only motion of a pointing device such as the system mouse. Motion of an alternative pointing device such as a head pointer or trackball can also be defined.

All gestures are speci- fied by the same syntax, there is no distinction between a 'core mouse' gesture and motion from an alternate input device. Motion gestures are defined as "crossing events" into and out of the login dialog window. If the 'dwellmouselistener' GtkModule is loaded, alternative pointing devices are temporarily "latched" to the core pointer, such that motion from alternative devices results in movement of the onscreen pointer.

To use text-to-speech services at login time for instance, when using the Screen Reader in speech mode on some operating systems, the gdm user must be a member of the "audio" group. Logging GDM uses syslog to log errors or status. GDM can also log debugging information, if enabled in the gdm. The output from the session can be found in a file called display. Four older versions of this file are also stored, by appending 1 through 4 to the file- name.

These files are rotated, as new sessions on that display are started. You can use these logs to view what the X server said when it started up.

xsession-errors before even the PreSession script is started, so it is not necessary to redirect this again in the session setup script. If the user session lasted less then 10 seconds, GDM assumes that the session crashed and allows the user to view this file in a dialog before returning to the login screen.

This enables the user to view the session errors from the last session and correct the problem. You can suppress the second warning by returning code 66 from the Xsessionscript or from your session binary the default Xsession script propagates those codes back. This is useful if you have special logins for which it is not an error to return less than 10 seconds later, or if you already set up the session to display an error message and the GDM message would be confusing and redundant.

xsession-errors file is capped by GDM at about kilobytes, to prevent a possible denial-of-service attack on the session. An application could, on reading some wrong data, print out warnings or errors on stderr or stdout. This could fill up the user's home directory, the user would then have to log out and log back in to clear this. This could be especially nasty if quotas are set. GDM also correctly traps the XFSZ signal and stops writing the file, which would lead to killed ses- sions if the file was redirected in the old-fashioned way from the script.

xsession-errors redirection and redirect in their own Xsession script set by the BaseXsession configuration key , which means that GDM cannot trap the output and cap this file. You also lose output from the PreSession script which can make debugging more difficult, as perhaps useful output of what is wrong is not printed out. See the description of the BaseXsession configuration key for more information, especially on how to handle multiple display managers using the same script.

XXXXXX, where XXXXXX are random characters. xsession-errors file, so that this log file is not stored unnecessarily.

conf file, the maximum file size that GDM should accept. If the face browser is enabled, a tunable maximum icon size is also enforced. On large systems, the face browser should be turned off for performance reasons. Looking up icons in home directories, scaling, and rendering face icons can take quite a long time.

In general, GDM is very reluctant to read or write user files. For instance, GDM refuses to touch anything but regular files. Links, sock- ets, and devices are ignored. The value of the "RelaxPermissions" parameter in the gdm.

conf file determines whether GDM accepts files that are writable by the user's group or others. These are ignored by default. Note that normally it is assumed that the home directory is only readable by the user. However, NFS traffic can be snooped. For setups with NFS directories, set the "UserAuthDir" parameter in the gdm. GDM tries to open the normal authorization file for reading as root. This can be changed by setting the "NeverPlaceCookiesOnNFS" parameter in the [security] sec- tion of the gdm.

conf file to "false". The script runs with root privileges and GDM blocks until the script terminates. Commands to set the background and so on should go in this file too. Search Forums. Search Community Posts. Today's Posts. Quick Links. Man Pages RedHat Commands OpenSolaris Commands Linux Commands SunOS Commands FreeBSD Commands All UNIX Man Pages All Linux Man Pages Full Man Repository.

Show Threads. Show Posts. Linux and UNIX Man Pages. gdm-binary 1m [opensolaris man page]. When no user is logged in on the console, GDM displays a graphical user interface that enables the user to enter their username and password.

GDM supports XDMCP and supports flexible or on-demand servers via the gdmflexiserver 1 command. gdm is a wrapper script that launches gdm-binary and passes along any options. Before launching gdm-binary the gdm wrapper script sources the profile 4 file to set the standard system environment variables.

conf where system defaults are stored. conf and any user settings defined there override the default settings. confdisplay where display is the display number, such as ":0". When GDM displays a GUI on the display, these per-display values override the values in the other configuration files. For each local display, gdm-binary forks an Xserver and a slave process.

The main gdm-binary process then listens to XDMCP requests from remote displays, if so configured, and monitors the local display sessions. The main daemon process also allows new local Xservers to start on demand using the gdmflexiserver 1 command.

The GDM slave process opens the display and starts either the Themed Greeter or the Plain Greeter. The parame- ter should be set to "gdmgreeter" to use the Themed Greeter or "gdmlogin" to use the Plain Greeter. The Plain Greeter is lower-bandwidth, which tends to be more appropriate for remote logins. The GDM daemon communicates asynchronously with the slave process through a pipe.

From either the Themed Greeter or the Plain Greeter, it is possible to launch the Chooser program gdmchooser to start remote XDMCP login sessions. conf file. The root password must be entered to launch the Setup program. The ability to launch the Setup program is disabled by default as gdmsetup 1m runs with root permissions and changing GDM configuration can affect security. GDM relies on PAM 3PAM Pluggable Authentication Modules for password authentication, but supports regular crypt and shadow passwords on legacy systems.

On Solaris, GDM uses logindevperm 4 to set proper device permissions for the user on login. All operations on user files are done with the effective user id of the user. If the sanity check fails on the user's. This means that none of the local servers from the [servers] section of the GDM configuration are run, and the console is not used to communicate errors to the user. An empty [servers] section automatically implies this option. You can use a single dash with this option to preserve compatibility with XDM.

This is mostly for debugging purposes. No greeter is shown until the GO message is sent. Also, flexiserver requests are denied and XDMCP is not started until GO is given. This is useful for initialization scripts that wish to start X early, but where you do not yet want the user to start logging in: the script sends the GO to the fifo when ready and GDM then continues.

The following options are supported by gdmlogin and gdmgreeter: gnome-std-options Standard options available for use with most GNOME applications. See gnome-std-options 5 for more information. This option is for running gdmchooser with xdm, and is not used within GDM. gnome-std-options Standard options available for use with most GNOME applications. The greeter contains a menu at the top, an optional face browser, an optional logo, and a text entry field.

The Plain Greeter corresponds to the executable gdmlogin. The text entry field is used to enter logins, passwords, passphrases, and so on. The field is controlled by the underlying daemon and is basically stateless. The daemon controls the greeter through a simple protocol where the daemon can ask the greeter for a text string with echo turned on or off. Similarly, the daemon can change the label above the text entry field to correspond to the value that the authenti- cation system wants the user to enter.

Optionally, the greeter can provide a face browser that contains icons for all of the users on a system. The icons can be installed glob- ally by the system administrator, or in the user home directories. png" appended. face, and can use gdmphotosetup 1 to graphically configure this. Face icons placed in the global face directory must be readable to the GDM user. However, the daemon proxies user pictures to the greeter. Therefore, those do not have to be readable by the GDM user, but must be readable by the root user.

Note that loading and scaling face icons located in user home directories can be a very time-consuming task, especially on large systems or systems running NIS. The browser feature is only intended for systems with relatively few users. Also, if home directories are on an on- demand mounted file system such as AFS, GDM might mount all of the home directories just to check for pictures if the face browser is on.

However, GDM will try to give up after 5 seconds of activity, and only display the users whose pictures have been received so far. When the browser is turned on, valid usernames on the machine are exposed to a potential intruder. This might be a bad idea if you do not know who has access to a login screen. This is especially true if you run XDMCP. Note that you should never run XDMCP on an open network.

The greeter can optionally display a logo in the login window. The image must be in a format readable to the gdk-pixbuf library GIF, JPG, PNG, TIFF, XPM , and must be readable by the GDM user. Themed Greeter The Themed Greeter is a greeter interface that is displayed on the whole screen and is themable.

The Themed Greeter corresponds to the exe- cutable gdmgreeter. The look and feel of this greeter is controlled by the theme, so the user interface elements that are present might differ. The only item that must always be present is the text entry field, as described in the Plain Greeter section above. You can display a menu of available actions by pressing the F10 key. This can be useful if the theme does not provide certain buttons when you wish to perform a particular action.

Chooser The Chooser displays a list of local machines that accept XDMCP connections. The user can also specify a machine by entering its name directly. Once a machine is selected, a remote XDMCP session can be started. The Chooser can be launched on the console directly from the Plain or Themed Greeter. The chooser corresponds to the executable gdmchooser.

XDMCP GDM can be configured to enable XDMCP so that users can log in remotely and launch a graphical chooser that allows a remote login session to be started.

See the [xdmcp] section of the default GDM configuration file. GDM grants access to the hosts specified in the GDM service section of your TCP Wrappers configuration file. GDM does not support remote display access control on systems without TCP Wrappers. GDM includes several measures that make GDM more resistant to denial-of-service attacks on the XDMCP service. Several protocol parameters, handshaking timeouts, and so on can be fine-tuned. The default values should work for most systems, however.

Do not change these values unless you know what you are doing. By default, GDM listens to UDP port , although this can be configured. GDM can also be configured to honor INDIRECT queries and present a host chooser to the remote display. GDM remembers the user's choice and forwards subsequent requests to the chosen manager.

GDM also supports an extension to the protocol which makes GDM forget the redirection once the user's connection succeeds. This extension is only supported if both daemons are GDM. This extension is transparent and is ignored by XDM or other daemons that implement XDMCP. GDM only supports the MIT-MAGIC-COOKIE-1 authentication system. Because of this, the cookies are transmitted as clear text. Therefore, you should be careful about the network where you use this.

That is, be careful about where your XDMCP connection is going. Note that if snoop- ing is possible, an attacker could snoop your password as you log in, so a better XDMCP authentication would not help you much anyway.

If snooping is possible and undesirable, you should use ssh for tunneling an X connection, rather then using GDM's XDMCP. Think of XDMCP as a sort of graphical telnet, with the same security issues. Controlling GDM You can control GDM behavior during runtime in several different ways. You can run certain commands, or you can talk to GDM using either a UNIX socket protocol, or a FIFO protocol.

You can control GDM behavior as follows: o To stop GDM, you can either send the TERM signal to the main daemon, or run the gdm-stop 1m command. o To restart GDM, you can either send the HUP signal to the main daemon, or run the gdm-restart 1m command.

o To restart GDM but only after all users have logged out, you can either send the USR1 signal to the main daemon, or run the gdm-safe- restart 1m command. The gdmflexiserver 1 command can be used to communicate with the GDM daemon and to start new flexible on demand servers. Configuration The GDM configuration files contain comments that explain each configuration parameter. Security GDM is best used with a dedicated user id and group id that GDM uses for graphical interfaces such as gdmgreeter, gdmlogin, and gdmchooser.

You can specify the name of this user and group in the [daemon] section of the GDM configuration file.

The UNIX and Linux Forums. Forum Home. Linux and Unix Man Pages. Search Forums. Search Community Posts. Today's Posts. Quick Links. Man Pages RedHat Commands OpenSolaris Commands Linux Commands SunOS Commands FreeBSD Commands All UNIX Man Pages All Linux Man Pages Full Man Repository.

Show Threads. Show Posts. Linux and UNIX Man Pages. gdm-binary 1 [sunos man page]. When no user is logged in on the console, GDM displays a graphical user interface that enables the user to enter their username and password.

GDM supports XDMCP and supports flexible or on-demand servers via the gdmflexiserver command. gdm is a wrapper script that launches gdm-binary and passes along any options. On startup, the GDM daemon parses its config file gdm. For each local display, gdm-binary forks an Xserver and a slave process.

The main gdm-binary process then listens to XDMCP requests from remote displays, if so configured, and monitors the local display sessions. The main daemon process also allows new local Xservers to start on demand using the gdmflexiserver command.

The GDM slave process opens the display and starts either the Graphical Greeter or the Standard Greeter. This choice is set by the "Greeter" parameter in gdm. conf for console login and the "RemoteGreeter" parameter for XDMCP logins. The parameter should be set to "gdm- greeter" to use the Graphical Greeter or "gdmlogin" to use the Standard Greeter. The Standard Greeter is lower-bandwidth, which tends to be more appropriate for remote logins.

The GDM daemon communicates asynchronously with the slave process through a pipe. From either the Graphical Greeter or the Standard Greeter, it is possible to launch the Chooser program gdmchooser to start remote XDMCP login sessions. Although disabled by default, it is also possible to launch the Setup program gdmsetup to edit the configuration choices in gdm. The root password must be entered to launch the Setup program.

The ability to launch the Setup program is disabled by default as gdmsetup runs with root permissions and allows GDM to be configured in ways that affect security. GDM relies on PAM, Pluggable Authentication Modules, for password authentication, but supports regular crypt and shadow passwords on legacy systems. On Solaris, GDM uses logindevperm to set proper device permissions for the user on login. All operations on user files are done with the effective user id of the user.

If the sanity check fails on the user's. OPTIONS The following options are supported by gdm and gdm-binary: --monte-carlo-sqrt2 --no-console Tell the daemon that it should not run anything on the console. This means that none of the local servers from the [servers] section of the gdm.

conf configuration file are run, and the console is not used to communicate errors to the user. An empty [servers] section automatically implies this option. You can use a single dash with this option to preserve compatibility with XDM.

This is mostly for debugging purposes. No greeter is shown until the GO message is sent. Also, flexiserver requests are denied and XDMCP is not started until GO is given. This is useful for initialization scripts that wish to start X early, but where you do not yet want the user to start logging in: the script sends the GO to the fifo when ready and GDM then continues.

The following options are supported by gdmlogin and gdmgreeter: gnome-std-optionStandard options available for use with most GNOME applications. See gnome-std-options 5 for more information.

This option is for running gdmchooser with xdm, and is not used within GDM. gnome-std-optionStandard options available for use with most GNOME applications. The greeter contains a menu at the top, an optional face browser, an optional logo, and a text entry field. The Standard Greeter corresponds to the executable gdmlogin. The text entry field is used to enter logins, passwords, passphrases, and so on.

The field is controlled by the underlying daemon and is basically stateless. The daemon controls the greeter through a simple protocol where the daemon can ask the greeter for a text string with echo turned on or off.

Similarly, the daemon can change the label above the text entry field to correspond to the value that the authenti- cation system wants the user to enter. Optionally, the greeter can provide a face browser that contains icons for all of the users on a system. The icons can be installed glob- ally by the system administrator, or in the user home directories. png" appended. face, and can use gdmphotosetup to graphically configure this.

Face icons placed in the global face directory must be readable to the GDM user. However, the daemon proxies user pictures to the greeter. Therefore, those do not have to be readable by the GDM user, but must be readable by the root user. Note that loading and scaling face icons located in user home directories can be a very time-consuming task, especially on large systems or systems running NIS.

The browser feature is only intended for systems with relatively few users. Also, if home directories are on an on- demand mounted file system such as AFS, GDM might mount all of the home directories just to check for pictures if the face browser is on.

However, GDM will try to give up after 5 seconds of activity, and only display the users whose pictures have been received so far. To filter out unwanted user names in the browser, the "Exclude" parameter in gdm.

conf can be set with a list of usernames separated by com- mas. The greeter automatically ignores the usernames listed, and excludes users whose UIDs are lower than the "MinimalUID" parameter, which is by default.

When the browser is turned on, valid usernames on the machine are exposed to a potential intruder. This might be a bad idea if you do not know who has access to a login screen. This is especially true if you run XDMCP. Note that you should never run XDMCP on an open network. The greeter can optionally display a logo in the login window. The image must be in a format readable to the gdk-pixbuf library GIF, JPG, PNG, TIFF, XPM , and must be readable by the GDM user.

Graphical Greeter The Graphical Greeter is a greeter interface that is displayed on the whole screen and is themable. The Graphical Greeter corresponds to the executable gdmgreeter. Themes can be selected and new themes can be installed by running gdmsetup, or by setting the "GraphicalTheme" parameter in gdm. The location of themes is specified by the "GraphicalThemeDir" parameter. The look and feel of this greeter is controlled by the theme, so the user interface elements that are present might differ.

The only item that must always be present is the text entry field, as described in the Standard Greeter section above. You can display a menu of avail- able actions by pressing the F10 key. This can be useful if the theme does not provide certain buttons when you wish to perform a particu- lar action.

Chooser The Chooser displays a list of local machines that accept XDMCP connections. The user can also specify a machine by entering its name directly. Once a machine is selected, a remote XDMCP session can be started. The Chooser can be launched on the console directly from the Standard or Graphical Greeter. The chooser corresponds to the executable gdmchooser. XDMCP GDM can be configured to enable XDMCP so that users can log in remotely and launch a graphical chooser that allows a remote login session to be started.

See the [xdmcp] section of the gdm. conf file. GDM grants access to the hosts specified in the GDM service section of your TCP Wrappers configuration file. GDM does not support remote display access control on systems without TCP Wrappers. GDM includes several measures that make GDM more resistant to denial-of-service attacks on the XDMCP service.

Several protocol parameters, handshaking timeouts, and so on can be fine-tuned. The default values should work for most systems, however.

Do not change these values unless you know what you are doing. By default, GDM listens to UDP port , although this can be configured. GDM can also be configured to honor INDIRECT queries and present a host chooser to the remote display.

GDM remembers the user's choice and forwards subsequent requests to the chosen manager. GDM also supports an extension to the protocol which makes GDM forget the redirection once the user's connection succeeds. This extension is only supported if both daemons are GDM.

This can be useful if the theme does not provide certain buttons when you wish to perform a particu- lar action. confdisplay where display is the display number, such as ":0". The following options are supported by gdmlogin and gdmgreeter: gnome-std-optionStandard options available for use with most GNOME applications. Forum Home. o If a user needs a pointing device without buttons or switches, include "dwellmouselistener". The UNIX and Linux Forums.

Categories:

• Forex Bitcoin
• Forex Brokers
• Binary Options
• Forex
• Binary Options online