retitle 1002527 milter-greylist -u user does not correctly ensure user can update greylist.db quit
* Adrian Bunk <b...@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
