diff options
| author | Brian Cameron <brian.cameron@sun.com> | 2006-02-13 18:47:21 +0000 |
|---|---|---|
| committer | Brian Cameron <bcameron@src.gnome.org> | 2006-02-13 18:47:21 +0000 |
| commit | 8632e2a5670d280c153a43b3b0b522f8c5369815 (patch) | |
| tree | 58aa800f6ae833d2ca1b28e27a8ffb036365ce25 /docs/C/gdm.xml | |
| parent | 90113edce31c7024c0ce17bf3c9e197626621d94 (diff) | |
| download | gdm-8632e2a5670d280c153a43b3b0b522f8c5369815.tar.gz | |
Fix calls to zenity so they work. Fixes bug #330892. Last minute updates
2006-02-13 Brian Cameron <brian.cameron@sun.com>
* config/Xsession.in: Fix calls to zenity so they work. Fixes
bug #330892.
* README, README.install, docs/C/gdm.xml: Last minute updates
before string freeze.
Diffstat (limited to 'docs/C/gdm.xml')
| -rw-r--r-- | docs/C/gdm.xml | 261 |
1 files changed, 133 insertions, 128 deletions
diff --git a/docs/C/gdm.xml b/docs/C/gdm.xml index 21ab30d4..322b01e8 100644 --- a/docs/C/gdm.xml +++ b/docs/C/gdm.xml @@ -3,7 +3,7 @@ "http://www.oasis-open.org/docbook/xml/4.1.2/docbookx.dtd" [ <!ENTITY legal SYSTEM "legal.xml"> <!ENTITY version "2.13.0.8"> - <!ENTITY date "02/10/2006"> + <!ENTITY date "02/13/2006"> ]> <article id="index" lang="en"> @@ -63,7 +63,6 @@ This manual describes version &version; of the GNOME Display Manager. It was last updated on &date;. </releaseinfo> - </articleinfo> <sect1 id="preface"> @@ -139,10 +138,10 @@ </title> <para> - GDM was written with simplicity and security in mind. GDM is a - replacement for XDM, the X Display Manager. Unlike its competitors - (X3DM, KDM, WDM) GDM was written from scratch and does not contain any - XDM / X Consortium code. + The Gnome Display Manager (GDM) is a display manager that + implements all significant features required for managing + local and remote displays. GDM was written from scratch and + does not contain any XDM / X Consortium code. </para> <para> @@ -166,22 +165,22 @@ The key/value pairs defined in the GDM configuration files and the location of these files are considered "stable" interfaces and should only change in ways that are backwards compatible. Note that - this includes functionaity like the GDM scripts (Init, PreSession, + this includes functionality like the GDM scripts (Init, PreSession, PostSession, PostLogin, XKeepsCrashing, etc.); directory locations (ServAuthDir, PidFile, etc.), system applications (SoundProgram), etc. - Some values depend on OS interfaces may need to be modified to work on - a given OS. Typical examples are HaltCommand, RebootCommand, - SuspendCommand, StandardXServer, Xnest, SoundProgram, and the - "command" value for each "server-foo". + Some configuration values depend on OS interfaces may need to be + modified to work on a given OS. Typical examples are HaltCommand, + RebootCommand, SuspendCommand, StandardXServer, Xnest, SoundProgram, + and the "command" value for each "server-foo". </para> <para> Note: distributions often change the default values of keys to support - their platform. Command-line interfaces for programs installed to - <filename>lt;bin></filename> are considered stable. Refer to your - distribution configuration to see if there are any - distribution-specific changes from the default GDM configuration and - for information for what support exists for these options. + their platform. Command-line interfaces for GDM programs installed to + <filename><bin></filename> and <filename><sbin></filename> + are considered stable. Refer to your distribution documentation to see + if there are any distribution-specific changes to these GDM interfaces + and what support exists for them. </para> <para> @@ -214,11 +213,13 @@ <para> GDM can be asked to manage a display a number of ways. Local displays are always managed when GDM starts and will be restarted when a user's - session is finished. Displays can also be requested via XDMCP and - flexible displays can be requested by running the - <command>gdmflexiserver</command> command, and such displays are not - restarted on session exit. These display types are discussed in the - next section. + session is finished. Displays can be requested via XDMCP, flexible + displays can be requested by running the + <command>gdmflexiserver</command> command. Displays that are started + on request are not restarted on session exit. GDM also provides the + <command>gdmdynamic</command> command to allow easier management of + displays on a multi-user server. These display types are discussed + further in the next section. </para> <para> @@ -230,12 +231,12 @@ <command>gdmlogin</command> as the GUI dialog program. The <command>gdmlogin</command> program supports accessibility while the <command>gdmgreeter</command> program supports greater themeability. - The GUI dialog is run as an unpriviledged user/group which is - described in the "Security" section below. The GUI dialog - communicates with the daemon via a sockets protocol and via standard - input/output. The slave, for example passes the username and password - information to the GDM daemon via standard input/output so the daemon - can handle the actual authentication. + The GUI dialog is run as the unpriviledged "gdm" user/group + which is described in the "Security" section below. The GUI + dialog communicates with the daemon via a sockets protocol and via + standard input/output. The slave, for example passes the username and + password information to the GDM daemon via standard input/output so + the daemon can handle the actual authentication. </para> <para> @@ -318,6 +319,14 @@ remote sessions. For example, the Actions menu which allows you to shut down, restart, suspend, or configure GDM are not shown. </para> + + <para> + Displays started via the <command>gdmdynamic</command> command are + treated as local displays, so they are restarted automatically on + when the session exits. This command is intended to more effectively + manage the displays on a multi-user server (many displays connected + to a single server). + </para> </sect2> <sect2 id="xdmcp"> @@ -397,6 +406,8 @@ The GTK+ Greeter is the default graphical user interface that is presented to the user. The greeter contains a menu at the top, an optional face browser, an optional logo and a text entry widget. + This greeter has full accessibility support, and should be used + by users with accessibility needs. </para> <para> @@ -452,7 +463,7 @@ <para> You can always get a menu of available actions by pressing the F10 key. This can be useful if the theme doesn't provide certain buttons when - you really wish to do some action. + you wish to do some action allowed by the GDM configuration. </para> </sect2> @@ -471,10 +482,10 @@ <para> By default, the face browser is disabled since revealing usernames on - the login screen is not appropriate on many systems for security - reasons and because GDM requires some setup to specify which users - should be visible. Setup can be done on the "Users" tab - in <command>gdmsetup</command>. This feature is most practical to use + the login screen is not appropriate on many systems for security + reasons. Also GDM requires some setup to specify which users should + be visible. Setup can be done on the "Users" tab in + <command>gdmsetup</command>. This feature is most practical to use on a system with a smaller number of users. </para> @@ -487,8 +498,8 @@ filename should be the name of the user, optionally with a <filename>.png</filename> appended. Face icons placed in the global face directory must be readable to the GDM user. However, the daemon, - proxies user pictures to the greeter and thus those don't have be be - readable by the GDM user, but root. + proxies user pictures to the greeter and thus those do not have be be + readable by the "gdm" user, but root. </para> <para> @@ -524,7 +535,7 @@ <para> Please note that loading and scaling face icons located in user home - directories can be a very time consuming task. Since it not + 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. Furthermore, GDM will give up loading face images after 5 seconds of activity and will @@ -533,7 +544,7 @@ specify a set of users who should appear on the face browser. As long as the users to include is of a reasonable size, there should not be a problem with GDM being unable to access the face images. - To work around these problems, it is recommended to place face images + To work around such problems, it is recommended to place face images in the directory specified by the <filename>GlobalFaceDir</filename> configuration option. </para> @@ -558,8 +569,8 @@ <para> When the browser is turned on, valid usernames on the computer are inherently exposed to a potential intruder. This may be a bad idea if - you don't know who can get to a login screen. This is especially true - if you run XDMCP (turned off by default). + you do not know who can get to a login screen. This is especially + true if you run XDMCP (turned off by default). </para> </sect2> @@ -724,8 +735,7 @@ <para> GDM uses PAM for username/authentication, though if your machine does not support PAM you can build GDM to work with shadow - passwords and crypt. Refer to the next section for more information - about PAM. + passwords and crypt. </para> <para> @@ -761,10 +771,10 @@ If you wish to make GDM work with other types of authentication mechanisms, such as SmartCards, you should implement this via writing a PAM module rather than by trying to modify the GDM - code. Refer to the PAM documentation on your system and this - issue has been discussed on the + code. Refer to the PAM documentation on your system. Also + this issue has been discussed on the <address><email>gdm-list@gnome.org</email></address> mail list, - so you can refer to the archives for more information. + so you can refer to the list archives for more information. </para> </sect2> @@ -781,9 +791,11 @@ The GDM daemon normally runs as root, as does the slave. However GDM should also have a dedicated user id and a group id which it uses for its graphical interfaces such as <command>gdmgreeter</command> and - <command>gdmlogin</command>. You can choose the name of this user - and group in the <filename>[daemon]</filename> section of the - configuration file. + <command>gdmlogin</command>. These are configured via the + <filename>User</filename> and <filename>Group</filename> + configuration options in the gdm.conf file. The user and group should + be created before running "make install". By default GDM + assumes the user and the group are called "gdm". </para> <para> @@ -791,22 +803,31 @@ All functionality that requires root authority is done by the GDM daemon process. This design ensures that if the GUI programs are somehow exploited, only the dedicated user privileges are available. - By default GDM assumes the user and the group are called `gdm'. - These are configured via the User and Group configuration options in - the gdm.conf file. The user and group should be created before - running "make install" </para> <para> It should however be noted that the GDM user and group have some - privileges that make them somewhat dangerous. For one they have - access to the X server authorization directory (the - <filename>ServAuthDir</filename>), which contains all the X server - authorization files and other private information. This means that - someone who gains the GDM user/group privileges can then connect to - any session. So you should not, under any circumstances, make this - some user/group which may be easy to get access to, such as the - user <filename>nobody</filename>. + privileges that make them somewhat dangerous. For one, they have + access to the X server authorization directory. It must be able + to read and write Xauth keys to + <filename><var>/lib/gdm</filename>. This directory should + have root:gdm ownership and 1770 permissions. Running + "make install" will set this directory to these values. + The GDM daemon process will reset this directory to proper + ownership/permissions if it is somehow not set properly. + </para> + + <para> + The danger is that someone who gains the GDM user/group privileges + can then connect to any session. So you should not, under any + circumstances, make this some user/group which may be easy to get + access to, such as the user <filename>nobody</filename>. + Users who gain access to the "gdm" user could also + modify the Xauth keys causing Denial-Of-Service attacks. Also + if a person gains the ability to run programs as the user + "gdm", it would be possible to snoop on running GDM + processes, including usernames and passwords as they are being + typed in. </para> <para> @@ -817,29 +838,6 @@ the filesystem to ensure that the GDM user does not have read or write access to sensitive files. </para> - - <para> - The necessity for a gdm userid/group is because the GDM user does - require certain special permissions. It must be able to read and - write Xauth keys to <filename><var>/lib/gdm</filename>. This - directory should have root:gdm ownership and 1770 permissions. Running - "make install" will set this directory to these values. You - will need to modify the configure/Makefile if you want to use a - different group than "gdm". The GDM daemon process will - reset this directory to proper ownership/permissions if it is somehow - not set properly. - </para> - - <para> - If the gdm user is set up properly and gdm user access is somehow - exploited, this means that the GDM user should only be able to - maliciously modify the Xauth keys causing potential - Denial-Of-Service attacks. If a person gains the ability to run - programs as the user gdm, it would be possible to snoop on running - GDM processes, including usernames and passwords as they are - being typed in. Therefore it is important to ensure that - the gdm user is disallowed login and has no default shell. - </para> </sect2> <sect2 id="xauth"> @@ -1023,9 +1021,10 @@ gdm: .your.domain </para> <para> - If you are a distro and want to set machine defaults, you should - make the proper edits in the <filename>gdm.conf-custom</filename> file - rather than editing the <filename>gdm.conf</filename> file. + If you are a distribution and want to set machine defaults, you should + edit the <filename>gdm.conf</filename> file rather than editing the + <filename>gdm.conf-custom</filename> file, so the distribution changes + are preserved as defaults. </para> <para> @@ -1048,7 +1047,7 @@ Greeter=/usr/lib/gdmgreeter <para> The configuration files (especially the <filename>gdm.conf</filename> and <filename>gdm.conf-custom</filename> files) contains useful - comments and examples, so read this for more information about + comments and examples, so read these for more information about changing your setup. </para> @@ -1946,7 +1945,7 @@ PostSession/ <varlistentry> <term>SoundProgram</term> <listitem> - <synopsis>SoundProgram=<filename><bin>/play</filename> (or <filename>%lt;bin>/audioplay</filename> on Solaris)</synopsis> + <synopsis>SoundProgram=<filename><bin>/play</filename> (or <filename><bin>/audioplay</filename> on Solaris)</synopsis> <para> Application to use when playing a sound. Currently used for playing the login sound, see the @@ -5872,7 +5871,7 @@ homogeneous="bool"> you must encode it. So for example to have the label of "foo<sup>bar</sup>", you must type: <screen> -<text">foo&lt;sup&>bar&lt;/sup&></text> +<text>"foo<sup>bar</sup>"</text> </screen> </para> @@ -6052,19 +6051,26 @@ custom-config=foo <sect1 id="accessibility"> <title>Accessibility</title> - <para> - GDM supports "Accessible Login" to allow users to log in to - their desktop session even if they cannot easily use the screen, mouse, - or keyboard in the usual way. This feature allows the user to launch - assistive technologies at login time by means of special - "gestures" from the standard keyboard and from a keyboard, - pointing device, or switch device attached to the USB or PS/2 mouse - port. It also allows the user to change the visual appearance of the - login UI before logging in, for instance to use a higher-contrast color - scheme for better visibility. GDM only supports accessibility with - the GTK+ Greeter, so the "Greeter" parameter in the GDM - configuration must be set to the GTK+ Greeter "gdmlogin" - </para> + <para> + GDM supports "Accessible Login" to allow users to log in to + their desktop session even if they cannot easily use the screen, mouse, + or keyboard in the usual way. Only the "Standard Greeter" + supports accessibility, so use this login GUI for accessibility + support. This is done by specifying the "Standard Greeter" + in the "Local" tab for the console display and specifying + the "Standard Greeter" in the "Remote" tab for + remote displays. Or you can modify the <filename>Greeter</filename> + configuration option by hand to be <command>gdmlogin</command>. + </para> + + <para> + The Standard Greeter supports the ability to launch assistive + technologies at login time via configurable "gestures" from + the standard keyboard, pointing device, or switch device attached to + the USB or PS/2 mouse port. Also the user can change the visual + appearance of the login UI before logging in, for instance to use a + higher-contrast color scheme for better visibility. + </para> <sect2 id="accessibilityconfig"> <title>Accessibility Configuration</title> @@ -6240,7 +6246,7 @@ GtkModulesList=gail:atk-bridge:dwellmouselistener:keymouselistener <para> Configuring GDM with the "--with-post-path=/usr/openwin/bin" on Solaris is - recommended. See comments in configure.ac file. + recommended for access to programs like Xnest. </para> </sect2> @@ -6263,44 +6269,44 @@ GtkModulesList=gail:atk-bridge:dwellmouselistener:keymouselistener </screen> <para> - In the PreSession scriptchown /dev/console to the user:group who - is logging into the console and ensure whatever permissions is - specified in /etc/logindevperm (0600 for the line above). Then - in the PostSession script chmod them back to root:root and - ensure 0600 this time (don't use the value in the - /etc/logindevperm file). Linux uses a different mechanism for - managing device permissions. + The PreSession script would need to be modified to chown + /dev/console to the user:group who is logging into the console + and ensure whatever permissions is specified in /etc/logindevperm + (0600 for the line above). Then in the PostSession script chmod + the device back to root:root and ensure 0600 this time (do not + use the value in the /etc/logindevperm file). Linux uses a + different mechanism for managing device permissions, so this + extra scripting is not needed. </para> </sect2> <sect2 id="solarisautomaticlogin"> <title>Solaris Automatic Login</title> <para> - By default, automatic login is not enabled by GDM, so you would - only notice this problem if you try to make use of it. Turning - this feature on causes your computer to login to a specified - username on startup without asking for username and password. - This is an unsecure way to set up your computer. Make sure to - read the PAM documentation (e.g. pam.d/pam.conf man page) and be - comfortable with the security settings before modifying your - configuration. + Automatic login does not work on Solaris because PAM is not + configured to support this feature by default. Automatic + login is a GDM feature that is not enabled by default, so you + would only notice this problem if you try to make use of it. + Turning this feature on causes your computer to login to a + specified username on startup without asking for username + and password. This is an unsecure way to set up your + computer. </para> <para> - To turn on automatic login on Solaris, refer to the PAM section - above. If using Solaris 10 or lower, then you also need to - compile the pam_allow.c code and install it to /usr/lib/security - (or anywhere and provide the full path in /etc/pam.conf) and - ensure it is owned by uid 0 and not group or world writable. - Now see automatic login work. Wasn't it worth it! I believe - these settings will be added someday, though Sun isn't quite - sure Automatic login is such a secure feature so we will - probably debate it further. + If using Solaris 10 or lower, then you need to compile + the pam_allow.c code provided with the GDM release and + install it to /usr/lib/security (or provide the full path + in /etc/pam.conf) and ensure it is owned by uid 0 and not + group or world writable. </para> <para> The following are reasonable pam.conf values for turning on - automatic login in GDM. + automatic login in GDM. Make sure to read the PAM documentation + (e.g. pam.d/pam.conf man page) and be comfortable with the + security implications of any changes you intend to make to + your configuration. </para> <screen> @@ -6348,7 +6354,7 @@ GtkModulesList=gail:atk-bridge:dwellmouselistener:keymouselistener <filename>RootPath</filename>, <filename>PasswordRequired</filename>, and <filename>AllowRemoteRoot</filename> options as described in the - Configuration section. + "Configuration" section. </para> </sect2> </sect1> @@ -6607,7 +6613,6 @@ Hosts=appserverone,appservertwo </address> </para> </sect1> - </article> <!-- Keep this comment at the end of the file |