I apologize for letting this hang for too long. Sadly, any more changes
are not going to be in bookworm.
On Wed, Mar 15, 2023 at 04:14:25AM +0100, Guillem Jover wrote:
> 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.
So we should check for _aide to be present, or is the current package
using dh_installsysusers robust enough so that we can assume _aide to be
there?
> > 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).
I'd like to be cooperative and help local admins to use other users as
well, but not to an extents that I would write tens of lines of codes to
"support" this. I'd just rather not slam a door unnecessarily, if that
makes sense.
> > > 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. :)
Yes, that will imply that. systemd-sysusers is provided by systemd
proper, and I do not plan on using adduser in aide.
> > > 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?).
Too late for bookworm, but noted for the next cycle. It will be a
suggests.
Greetings
Marc
