Hoi.
[Only the setgid topic in this message.]
[2019-01-23 19:28] Dmitry Bogatov <kact...@debian.org>
> [2019-01-21 22:47] markus schnalke <mei...@marmaro.de>
> >
> > > 4. Currently, if LOCKTYPE=dot, ./configure script forces Makefile to
> > > setgid installed `inc' binary. I patch it out, but you may want to
> > > add option to /not/ use setgid. It is headache for two-stage
> > > installation, used by most package managers (dpkg, rpm, ...)
> >
> > AFAICS, if you use dotlocking and the mail spool directory is not
> > writable for all possible users, then inc(1) has to have setgid
> > or you would have no locking. Or am I wrong?
>
> Correct. If inc(1mh) is not setgid, it will work, but keep complaining
> about inability to create lock file.
... and thus will not do any locking at all. In consequence, if
inc(1) is run twice at the same time on the same account it may
destroy (or duplicate) mail! If one uses inc(1) in a cronjob and
invokes it manually every once in a while -- a setup which I
consider possible -- we set his mail integrity at risk.
We need locking of the mail spool file.
Thus, if the mail spool is not world-writable (seems to be the
case in Debian) and we use dotlocking, then we have to be setgid
to have any locking at all.
Or we could use a different locking method to avoid having be be
setgid. But that causes trouble with NFS-mounted mail spools, I
think.
Have a look at the Debian Policy Manual 11.6.
https://www.debian.org/doc/debian-policy/ch-customized-programs.html#mail-transport-delivery-and-user-agents
You find there:
All Debian MUAs, MTAs, MDAs and other mailbox accessing
programs (such as IMAP daemons) must lock the mailbox in an
NFS-safe way. This means that fcntl() locking must be combined
with dot locking. To avoid deadlocks, a program should use fcntl()
first and dot locking after this, or alternatively implement the
two locking methods in a non blocking way. [3] Using the functions
maillock and mailunlock provided by the liblockfile* packages is
the recommended way to accomplish this.
This is why nmh uses liblockfile for locking. I haven't found it
patched in the Debian package. Have they included this upstream?
We could consider changing our locking setup if there is a way
that works over all systems. I'm no friend of this locking
method selection in the configure step. We only have it for
technical necessity. But today, it might only have historic
need -- I don't know. If we can implement a locking mechanism
that works reliably on all modern systems (maybe that's the
case for the fcntl()+dotlocking conbination), we should switch
to that and drop the locking method selection.
Does someone have knowledge in this topic or would want to
research on it?
Concerning the setgid of inc(1), the Debian Policy writes:
The mail spool is 2775 root:mail, and MUAs should be
setgid mail to do the locking mentioned above (and must obviously
avoid accessing other users’ mailboxes using this privilege).
The Debian Policy even motivates us to make inc(1) setgid ...
because it simply has to be for reliable locking.
Thus I suggest that you keep the setgid part as it is upstream.
meillo
