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
signature.asc
Description: signature
