Section 1.7. My Users Mess Up Their Desktops

1.7. My Users Mess Up Their Desktops

Once you've made all of these changes, you may want to keep your users from messing them up. While I personally prefer allowing every user to customize his system, your managers may not agree.

There are two basic approaches to this process. First, you can disable access to the key tools. Second, you can change ownership and permissions on associated configuration files to prevent changes by regular users.

If you're interested in more detailed information, there's an excellent discussion on configuring a standard KDE desktop environment at An excellent guide to configuring a standard GNOME desktop environment is available in a Gentoo wiki at, and you can also refer to the Red Hat Desktop Deployment Guide available at

You can also make your changes a part of the /etc/skel directory, which causes them to be copied into the home directories of all users created subsequently. For example, the following command creates the new user nancy; the -m option (not required on Red Hat/Fedora) creates Nancy's home directory in /home/nancy, and activates the defaults in /etc/default/useradd, copying the files from /etc/skel,with appropriate ownership and permissions, into Nancy's home directory:

 useradd -m nancy 

1.7.1. Disabling Changes on KDE

The KDE desktop configuration is driven by both default and individual configuration files. Naturally, what you do depends on what you want to customize; do you want a standard desktop for just a few users or for every user on your network?

The default configuration files depend on the distribution, as shown in Table 1-8.

Table 1-8. KDE default configuration directory


KDE default configuration directory

Red Hat/Fedora






Individual configuration files are stored in each user's home directory in the ~/.kde/share/config directory. If you haven't yet configured custom settings for a specific user, the user-specific configuration file probably does not yet exist.

Once you make desired changes to one individual's ~/.kde/ directory, you can copy it to the home directory of other users. You can also copy it to the /etc/skel directory. As described earlier, this directory is often used to populate the home directories of new users with standard configuration files.

The key to preventing changes by pesky users is the immutable flag. In KDE configuration files, you can specify it through [$i]. For example, to lock the standard configuration, I've added this flag to the beginning of each stanzafor example:


In any case, changes aren't displayed until the next time you log in to the KDE desktop environment.

1.7.2. Restricting Actions on KDE

The KDE desktop environment includes a number of options suitable for kiosks, which are common locations for public terminals. If you administer a public terminal, you'll probably want to freeze the desktop configuration of that terminal. What you do for workstations in an office may also incorporate some of the same limitations.

In the previous section, I've covered some of the things you can do to disable configuration changes. You can also restrict such actions as starting a command-line interface, running as the root user, or changing the background. Open a kdeglobals configuration file and start a stanza with the following title:

 [KDE Action Restrictions][$i] 

On a workstation, you may want to keep certain users away from the command-line interface. You can do so in this stanza with the following directive:


By default, users can also start applications from the Run Application window, invoked through Alt-F2. If you want to disable access to this window, add the following directive:


You can keep users from using any KDE utilities that require the root account with a directive such as:


But users don't need the root account to customize many things on the KDE desktop. You can further limit access to different modules in the KDE Control Center, in a different stanza, starting with:

 [KDE Control Module Restrictions][$i] 

Here, you can limit access to the modules of your choice. For example, if you want to keep users from changing their own KDE desktop backgrounds, add the following directive to this stanza:


To keep your users from changing their screensavers, include the following directive:


If you want to limit access to another module, you simply need to know the name, as defined in the output from the following command:

 kcmshell --list 

Then, to limit access to the module of your choice, just substitute the name of that module in the following directive:

 kde-module name.desktop=false 

1.7.3. Disabling Changes on GNOME

The key to a standard GNOME desktop environment is the GConf system. Readers familiar with Microsoft Windows might notice parallels to the Registry Editor. You can start the GConf editor with the gconf-editor command (normally, it's in the /usr/bin directory; on SUSE, it's in the /opt/gnome/bin directory). There are three types of GNOME settings. What each user sees is an amalgamation of these:


Mandatory settings can't be changed by regular users, unless they have access to the GConf system or the associated configuration files in the /etc/gconf/gconf.xml.mandatory directory. (For SUSE, it's the /etc/opt/gnome/gconf/gconf.xml.mandatory directory.) Mandatory settings supersede default settings.


Default and mandatory settings, taken together, define the standard desktop environment seen by regular users; however, default settings can be changed. The associated configuration files are in the /etc/gconf/gconf.xml.default directory. (For SUSE, it's the /etc/opt/gnome/gconf/gconf.xml.default directory.)


User-specific and customizable settings are stored in each user's home directory, in ~/.gconf. Configuring system-wide GNOME desktop settings

To configure system-wide settings on the GNOME Desktop Environment, open the GConf editor as the root user. In some distributions, this is possible only with the sudo command; for example, on Debian Linux, I can open GConf while logged in to the K Desktop Environment with the following command:

 sudo gconf-editor 

Some distributions return an error messaoe if you try to open GConf as root. In that case, use the sudo gconf-editor command as a regular user. Access to the sudo command for a regular user requires that user be configured as part of the /etc/sudoers file, which you can configure with the visudo command.

1.7.4. Disabling Menu Items on GNOME

Sometimes the easiest way to keep users from changing their standard desktop environments is to disable the GUI menu items. In other words, if the user doesn't see the administrative tool, he's less likely to want to try to use it.

You can disable KDE menu items with the KDE Menu Editor described in the first annoyance in this chapter, "I Want the Advantages of Both KDE and GNOME."

Default GNOME main-menu files are located in the /usr/share/applications directory. User-specific menu files are located in each user's home directory, in ~/.config/menus. Managing the GNOME menu items is a straightforward process; for example, if your SUSE Linux computers are configured with the GNOME Desktop Environment, and you want to disable GNOME menu-based access to the YaST configuration tool, move (don't delete) the YaST.desktop file from the /usr/share/applications directory. (I move it to my home directory, in case I ever want to restore the menu option.)

If you're already in the GNOME Desktop Environment, check your menu. The changes are shown immediately on the Red Hat/Fedora and Debian distributions. The changes aren't shown on SUSE Linux until the next time you start GNOME.

Now you can implement these changes to the other desktop systems on your network. Remember, if you're removing items from the GNOME desktop menus, you'll have to remove the corresponding items from the /usr/share/applications directory on each of your target systems.

Linux Annoyances for Geeks
Linux Annoyances for Geeks: Getting the Most Flexible System in the World Just the Way You Want It
ISBN: 0596008015
EAN: 2147483647
Year: 2004
Pages: 144
Authors: Michael Jang

Similar book on Amazon © 2008-2017.
If you may any questions please contact us: