Should g_get_homedir use $HOME

[Owen Taylor <otaylor redhat com>]

http://bugzilla.gnome.org/show_bug.cgi?id=2311

Covers the question of whether g_get_homedir() should obey $HOME if
it is set, or whether it always (on Unix) use the result of 
getpwuid[_r].

Actually, various complicated setups are proposed, but I think only
two make sense:

 * Use $HOME, and if not set, use the information from getpwuid[_r]

 * Use the information from getpwuid[_r], if getpwuid[_r] fails
   fall back to $HOME. [ I don't expect getpwuid() to fail, but it
   might possibly do so on "unix-like" systems that provide some
   sort of emulation ]

It turns out that most of this time, this is irrelevant. login sets
$HOME and until you switch users, it will be left unchanged. 
The case where it becomes an issue is with some "execute a program
as another user" commands. There is some difference in behavior
here.

 - sudo doesn't set $HOME unless the invoker explicitely asks for it
   to be set.

 - su (at least on Linux... it's not standardized) sets $HOME to the
   new user's home directory, unless it is passed the '-m' option.

 - usermode (Red Hat's pamified method of running privileged programs)
   has a somewhat strange algorithm:

   If the user authenticates as root, then it sets $HOME to ~root,
   if the configuration is such that the user doesn't have to authenticate
   as root, then it leaves $HOME untouched. Which seems to be more
   or less backwards.

Basically, the situation is:

 - If the user is intended to have the full permissions of the 
   target user, then it's safe (by definition) to get configuration
   settings from the original home directory. This can be:
  
    - Useful - think GTK+ theme and behavior settings, inheritance, 
      especially for things like high contrast themes. (But note
      that these frequently will come from the display these days,
      and for applications that use GConf, just looking in the
      right homedir probably won't get config reading going write.)

    - Problematical if writing to the original home directory is
      needed if the target user doesn't have permission to write
      or read there. (this problem can occur even for running things
      as the superuser -  think NFS homedirs.)

    - Problematical if the application wasn't written to expect
      that the configuration directory isn't owned by it
      (Think of the CORBA services in the GNOME desktop.)
    
 - If the user is not intended to have the full permissions of the 
   target user, then it's not safe to get configuration settings
   from the original home directory.

For the security issue, GLib doesn't have the information to tell;
I believe that sudo/usermode should reset $HOME unless it's clear
that the user is intended to have full permisssions as the
target user. Both sudo and usermode get this "wrong" currently,
so this might be an argument that we should ignore $HOME.

But for GTK+ apps anyways, we don't support the usage where they are
being invoked by a user not authenticated as root and running as root
even if the environment is fully cleared ... there are plenty of other
things than the enviroment to worry about ... X properties, keyboard
input, drag and drop, cut and paste.

So, to summarize the security security we have:
 
 - While it might make sense to rely on the sudo style application
   to reset $HOME if it isn't safe to look there, current sudo
   style applications don't seem to do this.

 - Ignoring $HOME is certainly safer, but we've already said we
   don't support this form of safety for GTK+. (Though g_get_homedir()
   isn't just used for GTK+ applications.)

I don't think there is a clear conclusion on the issue of security.

But for the issue of correct operation, things are clearer -- apps
in many cases would need special handling to deal with case where
$HOME is:

 - Not owned by the user
 - Not writeable
 - Not even readable

Since apps are in general _not_ written to deal with these situations
I think it's better to make g_get_homedir() not pay attention
to $HOME and to return the real homedir for the user. If apps
want to pay attention to $HOME, they can do:

 const char *homedir = g_getenv ("HOME");
 if (!homedir)
   homedir = g_get_homedir ();

Which isn't painful, though a little cumbersome. For the GTK+
usage of g_get_homedir() we don't lose too much from this change,
since interesting configuration (theme, keybinding theme,
UI tweaks) can be done as XSETTINGS on the display.

Regards,
                                        Owen