Bug 49357 - Do not use $HOME=/dev/null/ - Failed to open directory /dev/null
Do not use $HOME=/dev/null/ - Failed to open directory /dev/null
Status: NEW
Product: UCS
Classification: Unclassified
Component: General
UCS 4.4
Other Linux
: P5 normal (vote)
: ---
Assigned To: UCS maintainers
UCS maintainers
:
Depends on:
Blocks:
  Show dependency treegraph
 
Reported: 2019-04-26 14:26 CEST by Christina Scheinig
Modified: 2022-04-26 09:29 CEST (History)
7 users (show)

See Also:
What kind of report is it?: Bug Report
What type of bug is this?: 4: Minor Usability: Impairs usability in secondary scenarios
Who will be affected by this bug?: 5: Will affect all installed domains
How will those affected feel about the bug?: 2: A Pain – users won’t like this once they notice it
User Pain: 0.229
Enterprise Customer affected?: Yes
School Customer affected?: Yes
ISV affected?:
Waiting Support:
Flags outvoted (downgraded) after PO Review:
Ticket number: 2019041821000519, 2019062121000321, 2022040421000281
Bug group (optional):
Max CVSS v3 score:


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Christina Scheinig univentionstaff 2019-04-26 14:26:49 CEST
The customer reported, that is deamon.log and therefor his device is filled with this log messages:
Apr 18 15:32:44 dc001 systemd[2424]: Failed to open directory /dev/null/.config/systemd/user/run-user-4778.mount.wants: Not a directory
Apr 18 15:32:44 dc001 systemd[2424]: Failed to open directory /dev/null/.config/systemd/user/run-user-4778.mount.requires: Not a directory
Apr 18 15:32:44 dc001 systemd[2424]: Failed to open directory /dev/null/.local/share/systemd/user/run-user-4778.mount.wants: Not a directory
Apr 18 15:32:44 dc001 systemd[2424]: Failed to open directory /dev/null/.local/share/systemd/user/run-user-4778.mount.requires: Not a directory
Apr 18 15:32:44 dc001 systemd[23506]: Failed to open directory /dev/null/.config/systemd/user/run-user-4778.mount.wants: Not a directory
Apr 18 15:32:44 dc001 systemd[23506]: Failed to open directory /dev/null/.config/systemd/user/run-user-4778.mount.requires: Not a directory
Apr 18 15:32:44 dc001 systemd[23506]: Failed to open directory /dev/null/.local/share/systemd/user/run-user-4778.mount.wants: Not a directory
Apr 18 15:32:44 dc001 systemd[23506]: Failed to open directory /dev/null/.local/share/systemd/user/run-user-4778.mount.requires: Not a directory

We already have an article with a workaround but we should fix this in the product!

https://help.univention.com/t/problem-journalctl-reports-errors-failed-to-open-directory-dev-null-config-systemd/11874
Comment 1 Felix Botner univentionstaff 2019-07-01 10:23:29 CEST
I have seen this too, many many lines of this in the syslog (mainly because samba logons, which also go through pam) 

I wonder if we should make pam_systemd optional (with the default not use it).

If i recall correctly we have added this only for the ssh/reboot problem in our tests.

see also Bug #49382
Comment 2 Philipp Hahn univentionstaff 2019-07-03 13:31:15 CEST
(In reply to Felix Botner from comment #1)
> I wonder if we should make pam_systemd optional (with the default not use
> it).

"Do not shoot the messenger" - fix the underlying issue:

The error is to use the *character device* "/dev/null" as a home *directory*. That was never right and you already get it when doing something like this:
 $ univention-ssh /etc/machine.secret $HOSTNAME\$@$HOSTNAME /bin/true
 Could not chdir to home directory /dev/null: Not a directory

PS: Do NOT use a shared directory as that would just be a security problem.
Comment 3 Dirk Schnick univentionstaff 2022-04-12 09:10:22 CEST
Another customer has this problem. The syslog file for one day is about 1GB!
Also it looks like a replication was failed as the LDAP server run into a timeout during writing to disk. We need to fix this.
Comment 4 Ingo Steuwer univentionstaff 2022-04-20 14:41:26 CEST
(In reply to Dirk Schnick from comment #3)
> Another customer has this problem. The syslog file for one day is about 1GB!
> Also it looks like a replication was failed as the LDAP server run into a
> timeout during writing to disk. We need to fix this.

mhm, I don't think we should "blame" this bug if the replication fails, a system should be able to write 1GB log per day without breaking other services.
Comment 5 Ingo Steuwer univentionstaff 2022-04-20 14:44:53 CEST
(In reply to Philipp Hahn from comment #2)
> The error is to use the *character device* "/dev/null" as a home
> *directory*. That was never right and you already get it when doing
> something like this:
>  $ univention-ssh /etc/machine.secret $HOSTNAME\$@$HOSTNAME /bin/true
>  Could not chdir to home directory /dev/null: Not a directory
> 
> PS: Do NOT use a shared directory as that would just be a security problem.

If I understand correctly the $HOME of host accounts is /dev/null and leads to these messages / errors. Questions that come to my mind:

* What is a proper $HOME for host accounts?

/home/$HOSTNAME -> might conflict with usernames (no leading "$")?
/home/.$HOSTNAME
/home/hostaccounts/$HOSTNAME

* are only accounts for UCS instances affected, or also Desktops (Windows, Ubuntu, ...)?
Comment 7 Dirk Schnick univentionstaff 2022-04-25 16:44:04 CEST
A normal syslogfile is not bigger than 1 GB per day. Also a very lot of entries are these mount wants home entries.

As I have seen a lot of names I'm pretty sure windows client machines are affected.
Comment 8 Arvid Requate univentionstaff 2022-04-25 19:47:14 CEST
Re: Comment 5: "/home/$(hostname)$" would be the canonical way. But it's not very nice.

Another option may be the user runtime directory /run/user/$UID managed by pam_systemd


root@primary20:~# su - primary20$
su: warning: cannot change directory to /dev/null: Ist kein Verzeichnis
$ systemd-analyze --user unit-paths
/dev/null/.config/systemd/user.control
/dev/null/.config/systemd/user
/etc/systemd/user
/run/systemd/user
/dev/null/.local/share/systemd/user
/usr/local/share/systemd/user
/usr/share/systemd/user
/usr/local/lib/systemd/user
/usr/lib/systemd/user

Re: Comment 7:

> As I have seen a lot of names I'm pretty sure windows client machines are affected.

We should confirm that and see if we can find a different way to avoid this.
Possibly this offers more potential to skip unnecessary steps.