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