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

[Johannes Schauer]

Hi,

Quoting Michael Biebl (2020-02-05 19:16:03)
> 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?

Unfortunately, I have never heard of a problem where directories in the chroot
were owned by sbuild:sbuild instead of root:root. If you can reproduce the
issue, please file a bug against sbuild.

Thanks!

cheers, josch
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 833 bytes
Desc: signature
URL: <http://alioth-lists.debian.net/pipermail/pkg-systemd-maintainers/attachments/20200206/b34b260b/attachment.sig>