Bug 1296288

Cross-filed case 01562812 on the Red Hat customer portal.

Why so you want to change the owner of the symlink? Even normal chown follows the symlinks and does not change the permission of it.

This behavior is expected:
https://github.com/systemd/systemd/blob/master/src/tmpfiles/tmpfiles.c#L626

In systemd in rhal we don't have that check, so we might end chowning the target.

So we should backport https://github.com/systemd/systemd/commit/48b8aaa82724bc2d8440470f414fb0d2416f29c7

If I'm able to specify permissions for L+, my personal expectation is that
these permissions are applied to the symlink, not to the target. And given
the second commit, it doesn't seem to be really that much expected (for the
target). But what sense does it make to be able to specific access mode and 
ownership for a symlink, if it does not get applied at all (second commit)?

From what I can see, Z follows symlinks (even the documentation at
http://www.freedesktop.org/software/systemd/man/tmpfiles.d.html says
different). Having:

Z /var/spool/MIMEDefang 0750 defang defang - -
d /var/spool/MIMEDefang/.razor 0750 defang defang - -
L+ /var/spool/MIMEDefang/.razor/razor-agent.log - - - - /dev/null

leads to /dev/null with permissions 750 defang:defang. If I disable
the first line, /dev/null has correct permissions again. This needs
IMHO either to be fixed or to be clarified in the documentation. The

L+ /var/spool/MIMEDefang/.razor/razor-agent.log - defang defang - /dev/null

line by itself does not chown the target but does also not chown the
symlink. If that is expected behaviour, at least the documentation
should mention that setting owner/group for L+ doesn't do anything...

(In reply to Robert Scheck from comment #6)
> line by itself does not chown the target but does also not chown the
> symlink. If that is expected behaviour, at least the documentation
> should mention that setting owner/group for L+ doesn't do anything...

Quoting symlink(2):

The  permissions of a symbolic link are irrelevant; the ownership is ignored when following the link, but is checked when removal or renaming of the link is requested and the link is in a directory with the sticky bit (S_ISVTX) set.


But, as you mention, it would be nice to emphasize this behavior in the man pages, as it might not be obvious.

In addition to the patch in comment 4, we should also backport https://github.com/systemd/systemd/commit/0aaa263f1651cab2ae1a02ae64cbf523b21fb6e1.

By the way, given comment #7 regarding that the ownership might matter, it
IMHO should be possible to set a different ownership via systemd-tmpfiles.

Create a symlink in /tmp and allow a specific user or group to remove it. 
To be honest I can't imagine a real use-case for that.

Given I got a reminder via the support ticket: What exactly will be fixed/
changed using this RHBZ? Per comment #10, my original request won't happen
I guess?

No, I just want to backport this: https://github.com/systemd/systemd/commit/48b8aaa82724bc2d8440470f414fb0d2416f29c7
https://github.com/systemd/systemd/commit/0aaa263f1651cab2ae1a02ae64cbf523b21fb6e1

https://github.com/lnykryn/systemd-rhel/pull/14

Pushed to staging -> post

NEW VERSION:

:: [   LOG    ] :: Package versions:
:: [   LOG    ] ::   systemd-219-27.el7.x86_64
:: [   PASS   ] :: Creating tmp directory (Expected 0, got 0)
:: [   PASS   ] :: Command 'pushd /tmp/tmp.JwI6Bkx2nJ' (Expected 0, got 0)
:: [   PASS   ] :: Command 'useradd foo' (Expected 0, got 0)
:: [   PASS   ] :: Command 'groupadd bar' (Expected 0, got 0)
:: [   LOG    ] :: Duration: 0s
:: [   LOG    ] :: Assertions: 5 good, 0 bad
:: [   PASS   ] :: RESULT: Setup

::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::
:: [   LOG    ] :: bug 1296288
::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::

:: [   PASS   ] :: Command 'systemd-tmpfiles --create' (Expected 0, got 0)
:: [   PASS   ] :: Command 'ls -l  /run/hello2/' (Expected 0, got 0)
:: [   PASS   ] :: File '/var/tmp/tmp.1m3e8oXcb5' should contain 'root.*root.* hello2.test$'
:: [   PASS   ] :: File '/var/tmp/tmp.1m3e8oXcb5' should contain 'root.*root.* hello2.link -> /run/hello2/hello2.test$'
:: [   LOG    ] :: Duration: 0s
:: [   LOG    ] :: Assertions: 4 good, 0 bad
:: [   PASS   ] :: RESULT: bug 1296288


OLD VERSION:
:: [   LOG    ] :: Package versions:
:: [   LOG    ] ::   systemd-219-19.el7.x86_64
:: [   PASS   ] :: Creating tmp directory (Expected 0, got 0)
:: [   PASS   ] :: Command 'pushd /tmp/tmp.3mOpnl39DI' (Expected 0, got 0)
:: [   PASS   ] :: Command 'useradd foo' (Expected 0, got 0)
:: [   PASS   ] :: Command 'groupadd bar' (Expected 0, got 0)
:: [   LOG    ] :: Duration: 1s
:: [   LOG    ] :: Assertions: 5 good, 0 bad
:: [   PASS   ] :: RESULT: Setup

::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::
:: [   LOG    ] :: bug 1296288
::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::

:: [   PASS   ] :: Command 'systemd-tmpfiles --create' (Expected 0, got 0)
:: [   PASS   ] :: Command 'ls -l  /run/hello2/' (Expected 0, got 0)
:: [   FAIL   ] :: File '/var/tmp/tmp.0cFDE8bNiY' should contain 'root.*root.* hello2.test$'
:: [   PASS   ] :: File '/var/tmp/tmp.0cFDE8bNiY' should contain 'root.*root.* hello2.link -> /run/hello2/hello2.test$'
:: [   LOG    ] :: Duration: 1s
:: [   LOG    ] :: Assertions: 3 good, 1 bad
:: [   FAIL   ] :: RESULT: bug 1296288


Verified...

Since the problem described in this bug report should be
resolved in a recent advisory, it has been closed with a
resolution of ERRATA.

For information on the advisory, and where to find the updated
files, follow the link below.

If the solution does not work for you, open a new bug report.

https://rhn.redhat.com/errata/RHBA-2016-2216.html