On Tue, 2023-03-14 at 21:36:01 +0100, Marc Haber wrote: > On Thu, Mar 09, 2023 at 02:46:10PM +0100, Guillem Jover wrote: > > I think this might have been a problem with the systemd service, which > > does not seem to give the same POSIX capabilities as the capsh > > invocation. I can probably test this hypothesis by installing aide in > > one of my systemd-based systems. > > I have: > - made the docs a bit clearer > - added a NEWS.Debian file > - modified the error messages given by dailyaidecheck to refer to > the README > - tested a bunch of use cases: > * systemd, s-nail > * systemd, mailx > * systemd, none of the above > * sysvinit without capsh, s-nail > * sysvinit without capsh, mailx > * sysvinit without capsh, none of the above > * sysvinit with capsh, s-nail > * sysvinit with capsh, mailx > * sysvinit with capsh, none of the above > in all use cases the daily cron job seems to do the intended thing
Great, thanks! And sorry, was intending to do the tests I mentioned and propose more patches, but did not end up finding the time for this. But given the changes and tests you have done above, there's probably not much need for these anymore. Otherwise let me know, and I'm happy to adapt or update any of the patches or similar, or prepare new ones. > > I think the options here could be to match the POSIX capabilities for > > the systemd service to the ones used in capsh, which should then let > > the sendmail set-uid-root case work, in addition to the patch I > > provided, otherwise that seems like a regression for the systemd case. > > The fact that manual intervention is needed on systemd systems to > restore the mail capability is documented now. I will revisit this > post-bookworm and discuss this (again) with upstream, at this time of > the release process, I'd rather not interfere with this part of the > code. Given the changes you mention above, I guess this is good enough for now. I at least I'm good with the couple of local changes I did to restore this on that server, that ended up only requiring creating the user by hand and the changes under /etc (setting MAILCMD=mail and USER=_aide). > > Also another problem is that USER is currently hardcoded to root, so > > that makes the directory check fail. > > Where is it hardcoded? I have only seen code that honors what's read in > from defaults. > > That variable was renamed to AIDEUSER just in case there is a conflict > with the pre-set USER variable. > > > Ideally USER would get automatically > > set instead of hardcoding it to root though, as that makes a check fail, > > say with USER=$(id -u -n) or similar. Will prepare another patch with > > that too. > > I can't follow the issue here, can you explain more please? Ok, I've rechecked again the involved code, and I think I was probably assuming the capsh was not updating the USER envvar, thus incorrectly thinking the dailyaidecheck script was then always ending up with USER set to root. But this is not supposed to be the case as --user does change the envvar. So please disregard this for now, perhaps I botched my analysis when I was trying to fix this and conflated explicitly setting the user, while I also fixed the perms on disk by hand. Cannot recall, I've just commented out the explicit USER=_aide setting for now, and added a coupled of debug aids on the previously failing check, and will see if the daily cron run still works. Thanks, Guillem
