This bug is Linux-specific.

When Python cannot find the home directory of the user invoking it, it prints "'import site' failed; use -v for traceback".

This occurs only when both of these conditions are met:
1. /etc/passwd contains no entry for the current real UID
2. the HOME environment variable does not exist

To duplicate this bug, compile and run the attached program as root.
(This program assumes that 12345 is not a legitimate user on your system, and that Python is at /usr/bin/python ; if this is not the case then edit it accordingly.)

The problem is reproducible on a current Debian Linux system although with different results for current versions of Python (only security issues are accepted against 2.6).  Unlike with 2.6, 3.1 reports no error.  2.7 and 3.2 both fail with an exception:

Traceback (most recent call last):
  File "/usr/lib/python2.7/site.py", line 548, in <module>
    main()
  File "/usr/lib/python2.7/site.py", line 530, in main
    known_paths = addusersitepackages(known_paths)
  File "/usr/lib/python2.7/site.py", line 257, in addusersitepackages
    user_site = getusersitepackages()
  File "/usr/lib/python2.7/site.py", line 232, in getusersitepackages
    user_base = getuserbase() # this will also set USER_BASE
  File "/usr/lib/python2.7/site.py", line 222, in getuserbase
    USER_BASE = get_config_var('userbase')
  File "/usr/lib/python2.7/sysconfig.py", line 541, in get_config_var
    return get_config_vars().get(name)
  File "/usr/lib/python2.7/sysconfig.py", line 449, in get_config_vars
    _CONFIG_VARS['userbase'] = _getuserbase()
  File "/usr/lib/python2.7/sysconfig.py", line 198, in _getuserbase
    return env_base if env_base else joinuser("~", ".local")
  File "/usr/lib/python2.7/sysconfig.py", line 185, in joinuser
    return os.path.expanduser(os.path.join(*args))
  File "/usr/lib/python2.7/posixpath.py", line 256, in expanduser
    userhome = pwd.getpwuid(os.getuid()).pw_dir
KeyError: 'getpwuid(): uid not found: 12345'

I tried running bug.c using the svn head of python and got this:

Could not find platform independent libraries <prefix>
Could not find platform dependent libraries <exec_prefix>
Consider setting $PYTHONHOME to <prefix>[:<exec_prefix>]
Fatal Python error: Py_Initialize: Unable to get the locale encoding
LookupError: no codec search functions registered: can't find encoding
Aborted

I saw similar error on Python 2.6 installed on freeBSD.
I had test SVN server and wrote pre-commit hook using python. When remote developer commited his changes to repository, hook called os.path.expanduser and exception was raised:
        #  File "/usr/local/lib/python2.6/posixpath.py", line 259, in expanduser
        #    userhome = pwd.getpwuid(os.getuid()).pw_dir
        #KeyError: 'getpwuid(): uid not found: 12345'

So its not a just-Linux issue.

This issue remembers me the issue #6612 (failure if the current directory was removed): the fix was to ignore os.getcwd().

Attached patch ignores os.path.expanduser() error (KeyError) and keeps ~ in the path. Example without HOME var and with an non existent user (uid 12345):

----------------------
$ env -i ./python
>>> import sysconfig
>>> sysconfig.get_config_var('userbase')
'~/.local'

>>> sysconfig.get_paths(scheme='posix_user', expand=False)
{'platstdlib': '{userbase}/lib/python{py_version_short}', 'platlib': '{userbase}/lib/python{py_version_short}/site-packages', 'purelib': '{userbase}/lib/python{py_version_short}/site-packages', 'stdlib': '{userbase}/lib/python{py_version_short}', 'scripts': '{userbase}/bin', 'include': '{userbase}/include/python{py_version_short}', 'data': '{userbase}'}

>>> sysconfig.get_paths(scheme='posix_user')              
{'platstdlib': '~/.local/lib/python3.3', 'platlib': '~/.local/lib/python3.3/site-packages', 'purelib': '~/.local/lib/python3.3/site-packages', 'stdlib': '~/.local/lib/python3.3', 'scripts': '~/.local/bin', 'include': '~/.local/include/python3.3', 'data': '~/.local'}
----------------------

Example with an existant user but without HOME var:
----------------------
marge$ env -i ./python
>>> import sysconfig
>>> sysconfig.get_config_var('userbase')
'/home/haypo/.local'
>>> sysconfig.get_paths(scheme='posix_user')      
{'platstdlib': '/home/haypo/.local/lib/python3.3', 'platlib': '/home/haypo/.local/lib/python3.3/site-packages', 'purelib': '/home/haypo/.local/lib/python3.3/site-packages', 'stdlib': '/home/haypo/.local/lib/python3.3', 'scripts': '/home/haypo/.local/bin', 'include': '/home/haypo/.local/include/python3.3', 'data': '/home/haypo/.local'}
----------------------

Can someone explain how it can happen that a user has no home directory?

I discovered this while I was implementing and testing a sandbox for automatic evaluation of programs.

Can you be more precise?  IOW, why is this a Python bug rather than a system misconfiguration?  Note that I don’t know a lot about POSIX, so I’m open to change my mind.

I'm not sure whether POSIX warrants anything about this behavior, but nothing prevents a process from running with a UID not listed in /etc/passwd (or NIS, whatever). For example, sudo allows running a command with a UID not listed in the password database, see http://linux.die.net/man/5/sudoers :
"""
targetpw

If set, sudo will prompt for the password of the user specified by the -u flag (defaults to root) instead of the password of the invoking user. Note that this precludes the use of a uid not listed in the passwd database as an argument to the -u flag. This flag is off by default.
"""

UIDs not backed by users are useful for example if you're working with a sandbox, or virtual users such as in some FTP servers http://www.proftpd.org/docs/howto/VirtualUsers.html :
"""
Question: What makes a user "virtual", then?
Answer: A virtual user is, quite simply, a user that is not defined in the system /etc/passwd file. This file associates a user name, given by the system administrator, to a user ID (commonly shortened to UID) and a group ID (GID), among other details. The Unix kernel does not deal with users in terms of their user names; it only "knows" about UIDs and GIDs. This means that an application like proftpd can look up the IDs to use for a given user name however it sees fit. Using /etc/passwd is not strictly required.
"""

Because the patch is simple (just add a try/except), I think that it doesn't matter if only few people use users without entry in /etc/passwd and we should fix this issue.

It’s not just a try/except, it’s a behavior change: after the patch, paths returned by sysconfig may not be fully expanded paths.  I would like Tarek to make a call on this.

> I would like Tarek to make a call on this.

So Tarek, what do you think?

As discussed w/ Victor, a process should be able to run Python even if its user does not have a home.

So the call to _getuserbase() should be protected. 

But then we have to control that all the code that uses  CONFIG_VARS['userbase'] is protected when the value is not set.

I am thinking about per-user installation and such things: we need to make sure everything is checking this.

This is the one thing about which I wanted a call: “after the patch, paths returned by sysconfig may not be fully expanded paths” (i.e. they may start with '~').

Paths that are starting with ~ should be extended with the right value with the user base. If the user base cannot be calculated, paths starting with ~ should not exist or be used at all in this context.

Maybe we need to completely reset them to None like userbase. We need to list all use cases within the stdlib and come up with a general rule.

> If the user base cannot be calculated, paths
> starting with ~ should not exist or be used at all in this context.

It's not "~" but "{userbase}" substitution variable.

Here is a new patch implementing this idea: don't create the variables using the user directory if the user doesn't exist (if we cannot get the user directory). I didn't test distutils, I just try to start Python (it does work using bug.c).

@eric.araujo, @tarek: do you prefer nonexistent_user.patch? I removed sysconfig_getuserbase.patch, because I agree that an expanded path containing "~" is a bug.

In the absence of tests or doc update, can you tell in English what the new behavior is?  IIUC, when the home dir is not found, all the variables that depend on it would not exist, right?  Or would they be set to None?

Main changes of the patch, if the current user has no home directory (no entry in /etc/passwd) and there is HOME environment variable:

 - sysconfig.get_config_vars() doesn't have a 'userbase' variable. sysconfig.get_config_var('userbase') returns None as any other nonexistent key.
 - sysconfig.get_paths() doesn't create a path if expand fails (without raising an error or emiting a warning). For example, sysconfig.get_paths(scheme='posix_user') returns an empty dict.

Adding people from the duplicate report #14238.

Georg said:
> there should be a guard here that just doesn't add user site directories if the lookup fails.

I concurred and added:
> we also need to fix sysconfig; I think the right thing to do would be not to have a config var
> named 'userbase' when run from a UID without passwd entry.  This implies that the functions
> listed under http://docs.python.org/library/sysconfig#installation-paths would also need to omit
> *user schemes.

I reviewed haypo’s patch.  I’d be happy to update it to address my remarks if you want me to.

> I’d be happy to update it to address my remarks if you want me to.

Please write your own patch addressing your concerns.