When insider a container started by scuba, all processes are running as the UID of the user who invoked scuba. This is done intentionally, so that files created in the build directory (in the container) are owned by the user (who invoked scuba), and not as root.
This UID often does not exist in /etc/passwd in the container, meaning the user is considered "unknown". This problem manifests itself in various ways:
- In Bash, PS1 shows the following:
I have no name!@d2b465feee7c:/$ whoami
whoami: cannot find name for user ID 1000
- Python crashes during startup due to bug 10496. This happens only if
$HOME is not set1
I have no name!@d2b465feee7c:/$ unset HOME
I have no name!@d2b465feee7c:/$ python
Traceback (most recent call last):
File "/usr/lib/python2.7/site.py", line 563, in <module>
main()
File "/usr/lib/python2.7/site.py", line 545, in main
known_paths = addusersitepackages(known_paths)
File "/usr/lib/python2.7/site.py", line 272, in addusersitepackages
user_site = getusersitepackages()
File "/usr/lib/python2.7/site.py", line 247, in getusersitepackages
user_base = getuserbase() # this will also set USER_BASE
File "/usr/lib/python2.7/site.py", line 237, in getuserbase
USER_BASE = get_config_var('userbase')
File "/usr/lib/python2.7/sysconfig.py", line 582, in get_config_var
return get_config_vars().get(name)
File "/usr/lib/python2.7/sysconfig.py", line 533, in get_config_vars
_CONFIG_VARS['userbase'] = _getuserbase()
File "/usr/lib/python2.7/sysconfig.py", line 210, in _getuserbase
return env_base if env_base else joinuser("~", ".local")
File "/usr/lib/python2.7/sysconfig.py", line 196, in joinuser
return os.path.expanduser(os.path.join(*args))
File "/usr/lib/python2.7/posixpath.py", line 269, in expanduser
userhome = pwd.getpwuid(os.getuid()).pw_dir
KeyError: 'getpwuid(): uid not found: 1000'
It would be ideal if Scuba were to set up a more sane envionment, executing as a user that exists in the container.
1 This happens when executing Python from SCons which, by design, does not pass inherited environment variables through to sub-processes. ↩
When insider a container started by scuba, all processes are running as the UID of the user who invoked scuba. This is done intentionally, so that files created in the build directory (in the container) are owned by the user (who invoked scuba), and not as root.
This UID often does not exist in
/etc/passwdin the container, meaning the user is considered "unknown". This problem manifests itself in various ways:$HOMEis not set1It would be ideal if Scuba were to set up a more sane envionment, executing as a user that exists in the container.
1 This happens when executing Python from SCons which, by design, does not pass inherited environment variables through to sub-processes. ↩