Re: [systemd-devel] DynamicUser=yes leads to "Too many levels of symbolic links" for /etc/.pwd.lock

[Lennart Poettering]

On Do, 14.09.23 03:50, Muggeridge, Matt (matt.muggerid...@hpe.com) wrote:

> $ ls -l /etc/.pwd.lock
>
> lrwxrwxrwx 1 root root 19 Apr  5  2011 /etc/.pwd.lock -> sysconfig/.pwd.lock
>
> $ ls -l /etc/sysconfig/.pwd.lock
>
> -rw--- 1 root root 0 Aug 16 07:25 /etc/sysconfig/.pwd.lock
>
> For the purpose of investigation, I configured an overlay so /etc/.pwd.lock 
> was a simple writeable file (not a read-only symlink) and the service starts.
>
> Why is systemd complaining about the file being a symlink?

It's supposed to be a lock file, i.e. a regular file we issue POSIX file
locks on. It's not a config file.

The problem with symlinks for things like this is that in various
contexts these files are atomically replaced, and if that happens then
symlinks just make a mess, since it's not clear whether to replace the
symlink or its target.

Hence, we don't support that.

Generally, things like /etc/passwd is API pretty much, you cannot
really change it to a be a symlink (unless you make it fully
immutable), since it is updated by various tools and these tools tend
to do atomic updates of these files, i.e. when updating they write a
new file under a temporary name/O_TMPFILE, and then atomically move
it over the old file, so that other clients either get the old version
or the new version but never a half-updated version. This kind of
updating is really how you have to do things on UNIX, but that means
symlinks are out of the question...

Hence, TLDR: don't make the lock file a symlink. (Also, why would you even?)

Lennart

--
Lennart Poettering, Berlin

[systemd-devel] DynamicUser=yes leads to "Too many levels of symbolic links" for /etc/.pwd.lock

[Muggeridge, Matt]

Hi,

I'm using systemd-v254.

My rdisc service fails to start when "DynamicUser=yes", and the error message 
comes from 
systemd.execute.c.
 It's complaining about the /etc/.pwd.lock file (see journal below).

I turned on debug (systemd-analyze set-log-level debug) and then attempted to 
start the rdisc.service.  This is an extract from the journal:

$ journalctl -f
:

Sep 14 03:26:19 sph-093-rmc systemd[1]: rdisc.service: Forked /sbin/rdisc as 
24873

Sep 14 03:26:19 sph-093-rmc (rdisc)[24873]: Cannot open /etc/.pwd.lock: Too 
many levels of symbolic links

Sep 14 03:26:19 sph-093-rmc (rdisc)[24873]: rdisc.service: Failed to update 
dynamic user credentials: Too many levels of symboli

c links

Sep 14 03:26:19 sph-093-rmc (rdisc)[24873]: rdisc.service: Failed at step USER 
spawning /sbin/rdisc: Too many levels of symbolic

 links

Sep 14 03:26:19 sph-093-rmc systemd[1]: Sent message type=signal 
sender=org.freedesktop.systemd1 destination=n/a path=/org/freed

I can override it with "DynamicUser=no" and the service starts.  However, I'm 
trying to understand why it reports "too many levels of symbolic links". The 
lock file is a single-level symlink to a file in sysconfig.  (This is an 
embedded device, where /etc is read-only and /etc/sysconfig is writeable).


$ ls -l /etc/.pwd.lock

lrwxrwxrwx 1 root root 19 Apr  5  2011 /etc/.pwd.lock -> sysconfig/.pwd.lock

$ ls -l /etc/sysconfig/.pwd.lock

-rw--- 1 root root 0 Aug 16 07:25 /etc/sysconfig/.pwd.lock

For the purpose of investigation, I configured an overlay so /etc/.pwd.lock was 
a simple writeable file (not a read-only symlink) and the service starts.

Why is systemd complaining about the file being a symlink?

Regards,
Matt.