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

[Michael Biebl]

Am 05.02.20 um 18:15 schrieb 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.
> 

Johannes, could you chime in here?
Do you have some insight why /var/log might have these permissions?

Regards,
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/c58276b9/attachment.sig>