On Thu, 2023-03-09 at 14:39:37 +0100, Marc Haber wrote:
> On Sun, Mar 05, 2023 at 06:45:59PM +0100, Guillem Jover wrote:
> > # added updating to 0.18-1
> > rm -rf /var/tmp/aide.cron.daily /var/tmp/aide.cron.daily.old.*
> >
> > -if dpkg --compare-versions "$2" lt 0.17.5-1; then
> > +if dpkg --compare-versions "$2" lt "0.18-2"; then
>
> I am wondering why your postinst didn't trigger there. And I think if
> there is one person in Debian who knows how dpkg --compare-versions
> works then I am right now talking to him.
> Current stable has 0.17.3-4+deb11u1, and we had number of 0.17.4
> versions in testing during the bullseye cycle, so even the first version
> comparing with 0.17.5-1 should have always triggered the chown
> mechanisms, right?
I think I tried to cover this in the commit message, but perhaps it
was not very clear. This should have triggered, and the chown/chmod
calls executed, but because the user _aide had not been created then
the chown calls failed silently and their error codes got ignored.
I bumped the version because this needs to be re-executed once the
user is guaranteed to have been created. Otherwise when using the
_aide user, the tools will fail due to lack of permissions.
> > # we're updating from a version earlier than 0.17.5, chown logs and
> > databases
> > chown --quiet _aide:adm /var/log/aide /var/log/aide/aide.log
> > /var/log/aide/aide.log.* || true
> > + chown --quiet _aide:adm /var/log/aide/aideinit.log
> > /var/log/aide/aideinit.errors || true
> > chmod --quiet 2755 /var/log/aide || true
> > chown --quiet _aide:root /var/lib/aide/aide.db
> > /var/lib/aide/aide.db.new || true
>
> This would re-chown the other logfiles and the database for a user who
> had updated to 0.18-1 or 0.18-2 before and then decided to run aide with
> a different user. Wouldn't it be clearer to have a dedicated dpkg
> --compare-versions route for the forgotten aideinit.log, like:
>
> if dpkg --compare-versions "$2" lt 0.18-3; then
> # we're updating from a version earlier than 0.18-3, chown aideinit logs
> chown --quiet _aide:adm /var/log/aide/aideinit.log
> /var/log/aide/aideinit.errors|| true
> fi
See above. Also, I'd assume the supported users are root or _aide? Or
do you consider running under any arbitrary user configured by the
admin something to support? If the former, then if the admin has
decided to run the tools as root, then I'd assume the tools should have
enough permissions to write into the files even if they are owned by
_aide (but didn't try that in case they drop privs or similar).
> > Depends: aide (>= 0.17),
> > liblockfile1,
> > ucf (>= 2.0020),
> > + adduser | systemd-sysusers,
> > ${misc:Depends}
>
> This is hopefully handled by dh_installsysusers
(I assume that will imply having to install systemd-sysusers on a
system where adduser is already available if no adduser support is
added, which seems unfortunate, but better than not having the user
created. :)
> > Recommends: cron,
> > + libcap2-bin,
> > bsd-mailx | mailx | s-nail
>
> I'd rather not have this but document it in README.Debian to not pull in
> libcap2-bin on systemd systems which don't need that dependency. I have
> added a half-sentence mentioning libcap2-bin to README.Debian. The
> scripts should run fine without libcap2-bin installed and fall back to
> running as root instead.
If you find Recommends too strong, then it can always be added as a
Suggests, which is metadata available to the package managers and
frontends (perhaps even with a brief note in the Description?). Looking
into README.Debian is the last place I think when deciding whether I
might need to install additional packages needed by something.
Another option could be to declare this as «systemd-sysv | libcap2-bin»,
which keeps it as declarative, and handles the systemd case you are
concerned about.
Thanks,
Guillem
