Terminal emulators, utmp and setgid

Something that's been really irritating me recently on major Linux distributions is the increasing proportion of user software being installed setgid.

This is usually for security reasons; for instance, to either protect system services from accidental user interference, or to protect the user's personal information from being sniffed by other software they may be running.

Unfortunately, when a setgid executable is run, the environment is "cleaned"; potentially dangerous environment variables like TMPDIR and LD_LIBRARY_PATH get unset (this stops library preload attacks, for example).

But what if you want to have LD_LIBRARY_PATH set, for legitimate reasons?

The first set of breakage that bugged me was in xinit, where the call to start the window manager (which occurs after the user's login scripts are run) was wrapped in a call to SSH_AGENT. This effectively meant that it was not possible to set LD_LIBRARY_PATH for your window manager session at all. See Red Hat Bug #164869. Fortunately (a) there's a workaround available (see the bug discussion), and (b) it looks like this is going to be fixed soon(ish).

The second set of breakage was that several terminal emulators (xterm, konsole) are being installed setgid utempter. /var/run/utmp is a file which stores information on who is currently using the system. In order to protect it from malicious (or ignorant) users, it's protected by being only accessible to the utempter group, so in order to be able to be able to update it, terminal emulators need to be installed setgid.

I think this is stupid. It violates the rule of least surprise, and makes it difficult to debug environment variable problems in one's window session. Most of the workarounds are ugly hacks (like setting LD_LIBRARY_PATH in .bashrc, which is not what .bashrc is for).

Fortunately, I'm not the only one who thinks it's stupid, and now a change request has been filed against utempter, although goodness knows when it'll actually get fixed. See Red Hat Bug #246063.

The workaround for these problems I'm using at the moment is environment modules. I described the procedure to set it up in a posting to the gEDA user list.