GNOME, Wayland, and environment variables

The problematic change is simple enough to understand. While X sessions are started by way of a login shell in Fedora (even though the user never sees that shell directly), Wayland sessions do not involve a shell at all. As a result, the user's .bash_profile and .bashrc files (or whichever initialization files their shell uses) are not read. The place where this omission is most readily noticed is in the definition of environment variables. Many applications will change their behavior based on configuration stored in the environment; all of that configuration vanishes under Wayland. It also seems that some users (xterm holdouts, for example) still run applications that use the old X resources configuration mechanism. Resources are normally set by running xrdb at login time; once again, that doesn't happen if no login shell is run.

In your editor's case, this issue manifested itself in commands that should have been in $PATH not being found, and other programs misbehaving because the necessary environment variable definitions were not present. Commands run from a terminal emulator window work well enough (assuming the necessary definitions are in .bashrc rather than .bash_profile), but anything run directly from the session manager does not. Irritation ensues.

This particular problem, it seems, is not a surprise to anybody except those of us who update Fedora without reading the "common bugs" list first. It was first reported to the GNOME developers in 2014. Since then, discussion of the issue has gone back and forth, but no fix has been applied.

There's no end of possible ways to work around or fix this particular issue. One can, for example, make a simple tweak to the gnome-session script to cause it to run the user's shell of choice as part of starting up the session. This fix has not been applied, though, and it is not clear what solution the GNOME project will choose, if any, in the end.

The problem, it seems, is that shells and environment variables (not to mention xrdb) are seen as how our grandparents ran their computers. If one deals only with graphical applications, there is almost no scope for a shell to make an appearance at all, so it seems strange, to some, to involve the shell at login time. Environment variable definitions in shell startup files have been a common Unix customization method since the earliest days but, evidently, there is no easy place for that method in 2016.

So what should replace it? The conversation in the bug report covers a number of possibilities. Environment variables can be defined in a file added to /usr/share/gdm/env.d, but that, of course, requires privilege and sets those variables globally for all users. The pam_env authentication module can read variables from ~/.pam_environment, but only if the module is given the user_readenv=1 option — which is not the case on Fedora. The syntax of that file is also charmingly described as "a bit icky" in the discussion. One can run commands at startup by putting together a "desktop file"; that would be useful for commands like xrdb but not for the setting of environment variables, and even xrdb is tricky because it may not set the relevant resources before the applications using those resources are started.

Yet another approach is, naturally enough, to solve the problem in systemd. Red Hat's Ray Strode has put forward patches that do this by creating a new ~/.config/environment.d directory to hold user-specific environment-variable definitions. That takes the shell out of the picture, reducing flexibility, but it does solve the problem that (probably) affects the most users. The discussion on that patch set is long, and it touches on some legitimate security concerns. There may be an eventual solution in this direction, but no such thing has been merged into systemd as of this writing.

That leaves an increasing number of Fedora users, many of whom, it might be guessed, will not peruse the bug list before upgrading, who will run into this problem. Strode, for all that he wants to move on to a "modern" solution for environment variables, is clearly feeling the pressure that comes from wider exposure of a broken system. Thus, his most recent comment on the bug, as of this writing, reads: "Yea, I'm considering caving on this." So Fedora 25 is likely to see an update that restores the login shell to the login process; a "proper fix" will wait for later.

It is easy to write this episode off as another example of the GNOME developers happily breaking setups that have worked for years in the pursuit of some vision of a better way of doing things. And there is some truth to that. But there may also be truth to the idea that the mechanism used to customize the environment decades ago may no longer be ideal. Evolving the system toward a current understanding of the best and most secure approach makes a lot of sense. But it would be nice if we could get there without breaking large numbers of desktop setups.

That said, it's worth pointing out that the move to Wayland is a huge transition; we are moving away from a display manager that has been in place since before Linus Torvalds got his first computer. If that move brings about a seemingly unnecessary bit of breakage, we are surely entitled to grumble about it. But if that is all that goes wrong (and it seems that little else has gone wrong) then, once we've gotten the grumbling out of our system, we should recognize that such an easy change doesn't happen by chance. A lot of effort has gone into layers like XWayland and at the distribution level to keep applications working; that effort should be recognized and appreciated. A few glitches notwithstanding, this would appear to be a job well done.