Score:3

Home directory for user nobody - Ubuntu 20.04

in flag

I see a difference in the behaviour of the user "nobody" between Ubuntu 18.04 and Ubuntu 20.04.

In both (18.04 and 20.04) versions, the user nobody is configured as:

nobody:x:65534:65534:nobody:/nonexistent:/usr/sbin/nologin

In 18.04, for crontab applications, the home directory for nobody will be defined as HOME=/. In 20.04, crontab applications will report the home directory for nobody as non existent like

Failed to create secure directory (/nonexistent/.config/pulse): No such file or directory.

This is another example:

Ubuntu 18.04:

su - nobody
No directory, logging in with HOME=/
This account is currently not available.

Ubuntu 20.04:

su - nobody
su: warning: cannot change directory to /nonexistent: No such file or directory
This account is currently not available.

I guess that in 20.04 there is no default definition for users that have no valid home directory defined. How can we fix Ubuntu 20.04 so that it behaves like 18.04 (No directory, logging in with HOME=/).

waltinator avatar
it flag
`nobody` started as a fix for NFS - it mapped remote client `root` to `nobody` to avoid remote client `root` having `root` access to the server. Through feature creep, `nobody` has come to be used as a more general "no resources" account. Trying to use `nobody` via `su` and worrying about a home directory, etc is against `nobody`'s purpose. Don't do it.
IvanCN avatar
in flag
Hi, I understand this. But this aside, where does the difference come from?
Score:0
jp flag

I do not know how to make Ubuntu 20.04 su behave like Ubuntu 18.04 su.

The difference is because in Ubuntu 20.04/Focal su is provided by the util-linux package. In Ubuntu 18.04/Bionic su is provided by the login package (built from the source package shadow).

root@ubuntu:~# lsb_release -r
Release:        18.04
root@ubuntu:~# dpkg -S /bin/su
login: /bin/su
root@ubuntu:~# lsb_release -r
Release:        20.04
root@ubuntu:~# dpkg -S /bin/su
util-linux: /bin/su

A key implementation difference appears to be support for DEFAULT_HOME in /etc/login.defs. The manpage for Bionic's su mentions in its Configuration section

       DEFAULT_HOME (boolean)
           Indicate if login is allowed if we can't cd to the home directory. Default is no.

           If set to yes, the user will login in the root (/) directory if it is not possible to
           cd to her home directory.

The manpage for Focal's version of su does not mention DEFAULT_HOME.

I found a few relevant entries in the changelog for the shadow package

  * Use explicit --without-su configure flag
 -- Balint Reczey <[email protected]>  Fri, 20 Dec 2019 16:39:40 +0100
...
  * Drop Lintian override for su, it is not shipped in login anymore
 -- Balint Reczey <[email protected]>  Mon, 08 Jul 2019 15:58:46 +0200
...
  * Stop shipping su and break old util-linux version. (See #833256)
 -- Andreas Henriksson <[email protected]>  Fri, 27 Jul 2018 10:07:37 +0200

It looks like the change was made upstream in Debian and coordinated in https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=833256 . The lack of DEFAULT_HOME support is mentioned but is not considered a blocker.

mangohost

Post an answer

Most people don’t grasp that asking a lot of questions unlocks learning and improves interpersonal bonding. In Alison’s studies, for example, though people could accurately recall how many questions had been asked in their conversations, they didn’t intuit the link between questions and liking. Across four studies, in which participants were engaged in conversations themselves or read transcripts of others’ conversations, people tended not to realize that question asking would influence—or had influenced—the level of amity between the conversationalists.