Bug#1002527: postinst ignores USER from /etc/default/milter-greylist when invoking chown ... /var/lib/milter-greylist
retitle 1002527 milter-greylist -u user does not correctly ensure user can update greylist.db
quit
* Adrian Bunk <bunk@debian.org> [220120 21:43]:
> On Thu, Dec 23, 2021 at 02:12:04PM -0500, Marvin Renich wrote:
> >...
> > With an existing installation of milter-greylist set up to work with
> > chrooted postfix (i.e. USER="postfix" in /etc/default/milter-greylist),
> > every upgrade sets the owner of the directory /var/lib/milter-greylist
> > to "greylist" regardless of the setting of USER. This effectively
> > breaks postfix, as it will no longer deliver mail until the problem is
> > resolved.
> >
> > Note that the particular system hosting my mail server is still running
> > sysvinit, not systemd. I do not know how milter-greylist configures the
> > user under systemd, but the postinst has "greylist" hardcoded, so I
> > suspect that if the sysadmin has configured a different user, this will
> > break under systemd, as well.
> >...
>
> With systemd the problem likely doesn't exist since the user is
> hardcoded also in the service file:
>
> /lib/systemd/system/milter-greylist.service:
> ExecStart=/usr/sbin/milter-greylist -u greylist
I'm not sure how that fixes anything.
When I first migrated from exim to postfix (many years ago), the
recommendation to get milter-greylist to work with Debian's chroot'ed
postfix was to run milter-greylist as user postfix (I believe to get the
permissions correct on the socket created by greylist, or perhaps to
allow it to create the socket in the postfix chroot, or both).
milter-greylist had a documented way to run it as a different user by
setting USER="postfix" in the above file.
I don't have milter-greylist running with postfix on a systemd system,
so I can't test this, but I suspect that if I copied
/lib/systemd/system/milter-greylist.service to /etc/systemd/system/ and
edited it to use -u postfix, and corrected the ownership and permissions
on /var/lib/milter-greylist, the next upgrade would still clobber the
ownership, thus breaking postfix.
Doing some research (just now), I think I can get this working reliably
across milter-greylist upgrades by adding user postfix to the group
greylist, and running milter-greylist with its default user (greylist).
I will try this when I have a chance. But this is only a workaround for
the bug. As long as the package supports running as a different user,
an upgrade should not change ownership of /var/lib/milter-greylist.
More research has narrowed down the problem. This is not an
installation problem, but a failure of the "-u" option to perform its
documented behavior:
Make sure this user (and group) has write access to greylist.db.
Because every write to greylist.db is (at least seems to be) done by
writing a temporary file in the same directory and then atomically
renaming it, the above promise is equivalent to ensuring that the user
and group has write access to the containing directory. This is not
done at all. I am retitling this bug appropriately.
...Marvin
Reply to: