Bug#950684: systemd: upgrade fails in a chroot where /var/log/ owner is not root:root

[Michael Biebl]

Am 05.02.20 um 13:28 schrieb Michael Biebl:
> Am 05.02.20 um 13:22 schrieb Michael Biebl:
>> Am 05.02.20 um 10:47 schrieb Andrey Rahmatullin:
>>> Attached.
>>
>>
>>> Running create action for entry a /var/log/journal
>>> Detected unsafe path transition /var/log → /var/log/journal during canonicalization of /var/log/journal.
>>> Running create action for entry a /var/log/journal
>>
>> It appears this problem happens, if / is not owned by root:root and
>> doesn't have 755. Since you said that all your files/directories were
>> owned by sbuild:sbuild, it is likely that those messed up permissions
>> tripped up systemd-tmpfiles.
> 
> https://github.com/systemd/systemd/issues/11282

Sorry, should have read the bug report and your error message more
closely. It's obviously /var/log (and not /) which has the wrong
permissions. Otherwise the error message would have been different.

The reason why systemd-tmpfiles is complaining here, is that an
unprivileged user (sbuild) has access over subdirectories with higher
privileges and can fiddle with them (making it susceptible to a variety
of symlink attacks)

Now, the question: How should systemd postinst behave in this case?
Personally, I think throwing an error and letting the admin fix the
situation is probably not the worst solution.
Automatically fixing up the permissions in postinst is icky and I'd
rather not do that.
Simply ignore the error? Not sure, doesn't sound compelling either.

WDYT?

I have to add, that I just installed sbuild and created a sid chroot
which did not have those permissions for /var/log.
Maybe this was a bug in older versions of sbuild.

Michael




-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 833 bytes
Desc: OpenPGP digital signature
URL: <http://alioth-lists.debian.net/pipermail/pkg-systemd-maintainers/attachments/20200205/9d026484/attachment-0001.sig>