Hi, I am removing courier-maildrop (finally!), so it would be a good idea to package current upstream version, that is 2.8.3. There might be some bugs related to the courier-maildrop switch (but I have no idea why it shouldn't just work) and I'll reassign all old courier-maildrop bugs to maildrop package. Cheers, Ondrej
Hi, Yes. This was released during FREEZE. Since it involves library bumping etc., I did not update package via Debian patch ... Since release, you can only blame me for my lazyness... (was busy with others.) I have as much idea as you (or less...) Osamu
FYI: New 2.8.4-2 has been uploaded.
Hi,
Now we know it doesn't work. (I have reassigned another bug report to
courier in this regards.)
Here are the summary of differences and their compatibility.
OK 0001-sendmail-path.patch
NOT COMPAT. 0002-filter-permissions.patch
<--- permission rules are altered!
MAYBE 0003-permanent-err.patch
<--- This is build time dependent code is always set to 75
as if HAVE_COURIER is set.
MAYBE 0004-deliver-extra-newlines.patch
<--- I am not touching this bug fix.
OK 0006-postfix-docs.patch
OK 0007-reproduceble-sh.patch
OK 0008-upstram.patch
UNUSED 0010-maildrop-2.3.0-dovecotauth.patch
Unless these are addressed, it is difficult to be drop in replacement
for courier-maildrop.
Also, debian/rules has:
| override_dh_fixperms:
| dh_fixperms
| (cd debian/maildrop/usr/bin && chgrp mail maildrop lockmail.maildrop)
| (cd debian/maildrop/usr/bin && chmod g+s maildrop lockmail.maildrop)
Unless courier family of other tools play nice with this permission, there may be problem.
Regards,
Osamu
Hi, I've recently migrated my Courier MTA setup to stretch and had to go through a few hoops to get it to work, again. An important aspect was the courier-maildrop dump. With the packager's hat on, I'm also all for the drop and don't want to re-duplicate sources. This however means I'd like maildrop to handle the courier use case. The good news is: my virtual mail delivery setup via maildrop works if only I enable HAVE_COURIER for my custom-built maildrop package. Reading the sources, it doesn't seem feasible to just enable HAVE_COURIER for the general maildrop build, though. So I'd like to discuss some options that spring to mind: * change HAVE_COURIER into a dynamic flag: this might well have security implications that I'm unaware of. Note, however, that the courier-maildrop was SUID on root, while maildrop only has the SGID bit set for group 'mail'. So courier-maildrop was *more* of a security risk, not less. This could (or should?) possibly be extended by some mechanism that automatically detects whether or not courier is calling the maildrop executable. Extended (or different) behaviour could be prohibited for a non-courier caller. * build two different binaries from the maildrop source, one as it is, the other with HAVE_COURIER enabled. Are there other options? I'm certainly willing to help and hope to find a solution for stretch that fixes the courier use case. Kind Regards Markus Wanner
Hi, I just uploaded 2.9.3-1. (CCed recent uploaders) Yes. Excuse me for slow response. That is my understanding too. I am afraid such package is labeled with "security bug" again. That was the reason Debian maildrop split from courier-maildrop. This is one way. Hmmm.... this seems quite simple to do. Another option is create another wrapper code such as maildrop-suid-root which is a SUID on root program and let it calls maildrop in upstream. And make courier call this new code. This needs upstream cooperation. I don't want to maintain any SUID root program. Too much responsibility. If you are willing to take over this package maintenance, I can help 2 binary package script. Regards, Osamu
It doesn't make sense to add a new setuid root binary in the maildrop package. Whatever problem there is to solve, more setuid root by default is simply not a legitimate solution without a big fat obvious rationale about how it's unavoidable. Let's not jump to any such conclusions beforehand.
I brought up the issue on their mailing list, but upstream wasn't exactly cooperative. They think of maildrop being available in two different flavours: standalone and courier-mta bundle. I wonder if SUID is related at all. In my own setup, while using virtual domains in combination with maildrop, it wouldn't even need SGID, I think. But I'd have to check why it was SUID to begin with. Or if it is in the variant upstream installs. Kind Regards Markus Wanner
Hi,
I think the upstream is cooperating. It's mostly Debian internal issue,
I think.
flavours for jessie:
* maildrop (standalone): SGID mail
* courier-maildrop (previously available with courier-mta): SUID root
But for stretch, courier (0.75.0-15) maintainer changed this:
...
* Kill duplicate courier-maildrop package and just depend on standard
maildrop package
(Closes: #289091, #193650, #567462, #684230)
Upstream basically agrees with your assessment for our standalone use
case and accommodated it. But in the courier MTA use case, the upstream
apparently had need to keep this program setUID root and added some
extra codes to take advantage (code before the quoted section seems to
be for such purpose) of it and to limit it privilege as quoted in the
above.
You may be correct for your use case. I can only guess ... some courier
package which uses maildrop in "deliverymode" needs to set its UID and
GID to "courier:courier" to function. (At least the upstream thought
looks so to me.)
Technically building maildrop and courier-maildrop flavours of binary
packages from the same maildrop tarball is possible by fooling
configure.ac. I can help this technical part but for all the trouble of
securing setUID root is not my thing.
If the courier maintainer deems that he needs such special maildrop
custom build for courier mail security model while avoid having the 2
identical source base maintained and build independently in Debian, he
needs to step up to join and lead the maintenance of this maildrop
actively while taking full responsibility for the SUID root version.
The simpler thing to do than building 2 packages from the same maildrop
tarball is to revert the change in the courier package and not touching
the maildrop package. Then keep talking to share patches.
Regards,
Osamu
All of those changes related to HAVE_COURIER sound like something that should be possible to figure out on runtime. For example, it could detect some Courier-specific config file somewhere in /etc/, and then make those few subtle changes in behavior. I still don't see a rationale for that. The existence of those measly few lines about the HAVE_COURIER define, that we then have to interpret and reverse-engineer and whatnot - simply don't constitute a valid rationale for adding back a binary with suid root by default. I think we need to ask Sam to document this properly, and only then proceed with any further considerations.
That's exactly what I thought as well and proposed, but upstream rejected as an additional security risk. Exactly my line of thought as well. That's fine with me. Kind Regards Markus Wanner
Hi, I thought about this .... I now agree with you on the runtime detection approach you are talking. Relying on the existence of other files may not be the best idea. I now think of a simpler runtime detection method. If "maildrop" binary has its file permission with "suid root", HAVE_COURIER equivalent dynamic variable to be true. If a malicious user have right to set such capability to enable this, you system is already compromised. Maybe it's worth trying again with exact patch. If courier platform doesn't require it for sure, then please don't set suid root. If you need suid root for courier, add a courier-maildrop package which depends on maildrop and have postinst/rm script to set permission via dpkg-statoverride mechanism on the patched binary as discussed above. Or add README.Debian of maildrop to instruct this dpkg-statoverride trick without adding the courier-maildrop package. Yes. Anyway, let's forward debian/patches/0003-permanent-err.patch first. That will reduce one occurrence of HAVE_COURIER. This basically changes non-courier maildrop to behave like updated courier one. I think this moves key discussion of HAVE_COURIER to a single meaningful point. Regards, Osamu
Is the current situation still as described in the last comment? Last time I tried, this bug pervented maildrop to be used with Courier when configured with virtual accounts. I've been avoiding Courier and maildrop Debian packages since then. As for setuid root, yes, as far as I understand source code and manpage (https://www.courier-mta.org/maildrop.html#security), HAVE_COURIER builds of maildrop do need to run setuid root in order to provide the -D feature, which Courier uses to deliver messages to virtual accounts (and maybe other cases too). A quick glance at the source code makes me believe a patch to make HAVE_COURIER dynamic is not that hard to write. If you confirm that this bug is still unresolved I could try to write the patch and submit it upstream. Besides, I think it's overkill to check at runtime for setuid in order to behave like if HAVE_COURIER was present at build time: it's enough to check if the -D option is specified (the code to check that is already there) and, in that case, proceed assuming we are running with setuid root and with HAVE_COURIER at build time. If maildrop is not actually setuid root it will simply fail providing the -D feature (it only needs to be documented in the manpage), otherwise it will just work as intended by Courier. There are only two problems I see with this approach: 1) HAVE_COURIER declares an additional global variable before we can check for -D (namely "const char *numuidgid = 0;"), so we need to declare that variable regardless and use it only in -D case. I think this is not grave at all. 2) Users that want to run maildrop with Courier will need to setuid root the maildrop binary themselves, after the usual "apt install", so it does not work out of the box. I don't know if a manual setuid root operation is acceptable under all the Debian packaging guidelines and rules and whatever.
I have recently taken over maintenance of the maildrop package. My intention is to eventually reintroduce the courier-maildrop package as well, which should resolve this issue. However, first I need to get all of the courier packages into shape, which might take a while.