Linux.com

Feature

How to keep users from messing up their desktops

By Michael Jang on June 16, 2006 (8:00:00 AM)

Share    Print    Comments   

While I prefer allowing every user to customize his system, some managers may want to keep users from messing up a standard configuration. 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.

This article is excerpted from the recently published book Linux Annoyances for Geeks (ISBN 0-596-00801-5). Copyright 2006 O'Reilly Media, Inc. All rights reserved.

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:

KDE default configuration directory

Distribution

KDE default configuration directory

Red Hat/Fedora

/usr/share/config

SUSE

/opt/kde3/share/config

Debian

/etc/kde3

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, which 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 stanza -- for example:

  [Desktop0][$i]  

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

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 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:

  shell_access=false  

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:

  run_command=false  

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

  user/root=false  

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:

  kde-background.desktop=false  

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

  kde-screensaver.desktop=false  

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  

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

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

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

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 message 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.

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.

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.

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

Share    Print    Comments   

Comments

on How to keep users from messing up their desktops

Note: Comments are owned by the poster. We are not responsible for their content.

homicide...

Posted by: Anonymous Coward on June 17, 2006 08:13 AM
...Is the only way to prevent (l)users from "messing up".

This article does not include a method to induce deafness in the sysadmin, to prevent them from hearing the torrent of whining, threats, and long convoluted explainations of why "I just gotta change one little thing,...".

Smith and Wesson are the answers.

You CANNOT run a system this way, unless you want to spend transfinite time doing all the silly and useless crap the users wanna do themselves for no good reason that you have locked them out of.

Just be able to restore a std, working desktop to the creative luser. Then shoot the bastard.

#

Perhaps something in between

Posted by: Grant Johnson on June 17, 2006 10:55 AM
Take away all permissions outside of the home directory. They can do what they like, inside of their home, even install applications, as long as everything is in the home. Now install the things they need to do their jobs in their normal places.

When something goes terribly wrong, rm -Rf<nobr> <wbr></nobr>/home/moron

They still have what they need, but their customizations are gone because they messed it up. You could even do something a little less drastic like mv<nobr> <wbr></nobr>/home/moron<nobr> <wbr></nobr>/home/moron.`date %Y%m%d` Their stuff is still on the drive and they can still get to it, but they start with a clean slate.

I created a user on my PC for my young son to play with (20 months) and he can make quite a mess, but when it becomes unmanageable, I just empty his home directory and let him start with a clean slate again.

#

Re:Perhaps something in between

Posted by: Anonymous Coward on June 18, 2006 01:45 AM
I think we agree on the basic point that we cannot lock down a system tight enough to idiot-proof it, and still have a system acceptable to the idiots. Best we can do is limit the damage and prepare to recover to a minimum productive system.

Your 20mo old probably has more on the ball than most of the corporate droolers. Give him and MBA and he will probably forget his potty training.

#

Linux users mess up stoping it is simple

Posted by: Anonymous Coward on June 20, 2006 08:03 PM
Don't give them owner ship of there home directory.

Don't give them owner ship of desktop entrys or menu entrys. Desktop configs and the like they don't need to be changing.

For some tasks don't give them access to Windows manager and termials if they don't need it.

Ok console operatators can still add applications but they have to go to console to use them. Now this gets even better lock of console and non X11 term access without edit rights on there<nobr> <wbr></nobr>.bashrc files and the like they will not be editing them. Now they have to be really experenced person to get around this. Or able to exploit a flaw in something to get to a higher user.

Common misunderstanding that user has to own home directory they only have to have read only permissions on there group. Same with a lot of applications.

This is fort nox of setups. Most users hate it. This is great for a critical desktop to be operational. Since most of its untouchable.

I am a creative Linux/Windows User. Most of my creativitly is breaking open desktops to recover data because people loss passwords. It really does not make any difference how high the defence is if you forget the basics. Bios password. Fake login screen protection sysrq-k on linux anyone windows version of this please. Caused blue screen of death is not really the best way. Yes my kernels have this.

Because if a locked down user can break there account enough to fake a login screen and get a user with more access rights what is the point of the lock down.

#

aaaaarrrrggghh...

Posted by: Anonymous Coward on June 17, 2006 02:29 AM
...policy for Linux !!!

#

Interesting...

Posted by: Anonymous Coward on June 17, 2006 05:20 PM
But how do you edit the menu when you right-click on the background?

For there to be a "Change Desktop Background", yet no terminal is surely a misprioritisation for many...

#

read-only

Posted by: Anonymous Coward on June 18, 2006 07:28 AM
Couldn't you just make ~/.kde/share/ read-only? (I don't have anything to test this on right now.)

#

Re:read-only

Posted by: Anonymous Coward on June 18, 2006 09:55 AM
I can imagine so, but I don't believe it's a secure solution - the user always has permissions on that folder to grant write access.

#

Re:read-only

Posted by: Anonymous Coward on June 18, 2006 03:04 PM
Not if you make root the owner.

#

Re:read-only

Posted by: Anonymous Coward on June 20, 2006 08:46 PM
Well, just making that read only will produce a lot of confusing error messages for the users. That really isn't the way to do it, though it is simple.

#

Pessulus and Kiosk

Posted by: Anonymous Coward on June 18, 2006 12:55 PM
Take a look at:

- Pessulus in Gnome

- Kiosk admin tool in KDE

#

Gnome Lockdown features

Posted by: Anonymous Coward on June 24, 2006 09:09 PM
Since gnome 2.12 some tools for GNOME Desktop administrators were released. Those apps are pessulus and sabayon.

pessulus is the lockdown editor, while saboyon allow the administrator to profile a desktop for users and apply it where necessary.

#

Wow the LSB has a lot of progress to make

Posted by: Administrator on June 21, 2006 04:44 PM
3 distros, 3 locations for something as important as KDE (or Gnome). That can't be good.

#

reboot

Posted by: Anonymous [ip: 86.88.180.124] on February 10, 2008 04:32 PM
The account wich I have restricted hangs just after the login screen, so that I have to reboot

#

How to keep users from messing up their desktops

Posted by: Anonymous [ip: 24.72.39.65] on February 17, 2008 05:32 AM
the best way in my opinion to stop this problem is idiot-genocide... simple as that... lock them in a room full of windows based machines and watch them rot to death at the horridness surrounding them.

#

This story has been archived. Comments can no longer be posted.



 
Tableless layout Validate XHTML 1.0 Strict Validate CSS Powered by Xaraya