FS#56966 - [ndisc6] 1.0.3 rdnssd: Cannot write /var/run/rdnssd/resolv.conf.tmp: Permission denied

Attached to Project: Arch Linux
Opened by Sascha Wilde (swilde) - Friday, 05 January 2018, 18:14 GMT
Last edited by Buggy McBugFace (bugbot) - Saturday, 25 November 2023, 20:22 GMT
Task Type Bug Report
Category Upstream Bugs
Status Closed
Assigned To Christian Hesse (eworm)
Felix Yan (felixonmars)
Architecture All
Severity Medium
Priority Normal
Reported Version
Due in Version Undecided
Due Date Undecided
Percent Complete 100%
Votes 0
Private No

Details

Description:

rdnssd can't write /var/run/rdnssd/resolv.conf.tmp so that DNS setup
via IPv6 Router Advertisement isn't possible.

The reason is a problem related to systemd:
- /var/run/rdnssd is created by systemd-tmpfiles based on:
the information in /usr/lib/tmpfiles.d/ndisc6.conf:
d /run/rdnssd 0755 nobody root
- BUT the directory is not created with the UID 99 for nobody
as owner (as configured for arch linux in /etc/passwd) but with
the UID 65534 (which seems to be some defacto standard for
'nobody' on some other distros).
- This mismatch is hard to detect, as `ls -l' shows 65534
and 99 _both_ as "nobody".

Additional info:
* upstream systemd problem report:
https://github.com/systemd/systemd/issues/7032

Steps to reproduce:
* Check ownership with:
ls -lnd /var/run/rdnssd
* for a full reproduction it is necessary to setup a radvd with RDNSS
configured and install rdnssd (via ndisc6) ion the client.
This task depends upon

Closed by  Buggy McBugFace (bugbot)
Saturday, 25 November 2023, 20:22 GMT
Reason for closing:  Moved
Additional comments about closing:  https://gitlab.archlinux.org/archlinux/p ackaging/packages/ndisc6/issues/1
Comment by Sascha Wilde (swilde) - Friday, 05 January 2018, 18:15 GMT
A (questionable) workarount is to change the content of /usr/lib/tmpfiles.d/ndisc6.conf to:

d /run/rdnssd 0755 99 root
Comment by Doug Newgard (Scimmia) - Saturday, 06 January 2018, 22:43 GMT
Since the tmpfiles entry specifically says "nobody", it will use whatever "nobody" is on your system. It sounds like you've got something strange going on in /etc/passwd.
Comment by Sergej Pupykin (sergej) - Monday, 08 January 2018, 12:54 GMT
It looks like systemd problem. I got the same with dbmail.

In passwd nobody=99, but in /usr/lib/sysusers/basic.conf nobody=65534

systemd-tmpfiles uses basic.conf and ignores password. May be it can be fixed in nss switch.
Comment by Eli Schwartz (eschwartz) - Monday, 08 January 2018, 15:33 GMT
  • Field changed: Attached to Project (Community Packages → Arch Linux)
  • Field changed: Summary ([ndisc6] 1.0.3 rdnssd: Cannot write /var/run/rdnssd/resolv.conf.tmp: Permission denied → [systemd] [ndisc6] 1.0.3 rdnssd: Cannot write /var/run/rdnssd/resolv.conf.tmp: Permission denied)
  • Field changed: Status (Unconfirmed → Assigned)
  • Field changed: Category (Packages → Upstream Bugs)
  • Field changed: Severity (High → Medium)
  • Task assigned to Dave Reisner (falconindy), Christian Hesse (eworm)
That systemd bugreport looks to be something somewhat different, as this issue manifests regardless of --root.
Comment by Christian Hesse (eworm) - Monday, 08 January 2018, 19:07 GMT
IMHO systemd behaviour is not perfectly sane here, but nothing to blame.
A service running as "nobody" should not own nor write private files. Everything else is just broken. So if the service writes file... Fix it. Create a dedicated (or dynamic) user and use that.
Comment by loqs (loqs) - Tuesday, 09 January 2018, 23:06 GMT
@sergej systemd-tmpfiles is not using /usr/lib/sysusers/basic.conf but the current version is using the GID/UID 65534 the value appears to be build time configured in systemd
$ cat /etc/tmpfiles.d/test.conf
f /tmp/demo - nobody nobody
$ getent passwd nobody
nobody:x:65530:65534:Nobody:/:/sbin/nologin
$ grep nobody /usr/lib/sysusers.d/basic.conf
# The nobody user for NFS file systems
u nobody 64534 "Nobody" -
So if it uses passwd it should set it to 65530 if it uses basic it should use 64534
$ ls -lan /tmp/demo
ls: cannot access '/tmp/demo': No such file or directory
# systemd-tmpfiles --create test.conf
$ ls -lan /tmp/demo
-rw-r--r-- 1 65534 65534 0 Jan 9 22:58 /tmp/demo
65534 so the value did not come from passwd or basic.conf
Comment by loqs (loqs) - Tuesday, 09 January 2018, 23:14 GMT
https://github.com/systemd/systemd/commit/7e61fd02b0a9b2c4455974eb795da08b39352927 appears to be the commit that caused the change
also causes issues such as this and  FS#56828 
Comment by Dave Reisner (falconindy) - Saturday, 05 January 2019, 14:08 GMT
Is using RuntimeDirectory=rdnssd not an option here? It's substantially better than using tmpfiles.d.
Comment by Buggy McBugFace (bugbot) - Tuesday, 08 August 2023, 19:11 GMT
This is an automated comment as this bug is open for more then 2 years. Please reply if you still experience this bug otherwise this issue will be closed after 1 month.

Loading...