Bug#987009: courier-authlib: the purported fix for #984810 breaks maildrop "delivery mode"

2021-04-15 Thread Flavio Stanchina

On 15/04/21 16:40, Markus Wanner wrote:

Control: tags -1 + moreinfo

On 15.04.21 16:20, Flavio Stanchina wrote:
The fix for #984810 breaks maildrop "delivery mode" because maildrop is 
no longer able to look up user details after dropping privileges (or at 
least this is what I think is happening, from my understanding of how 
"delivery mode" works).


Hm.. shouldn't the user running maildrop be part of the 'courier' group? I 
don't think that's sufficient justification for making the information 
world-readable.


Ah, I didn't consider that; or rather, I thought it was but I forgot that 
dspam is running as its own user/group. However, after adding user "dspam" 
to group "courier" it's still not working:


Apr 15 17:01:29 stanchina dspam[6766]: Delivery agent returned exit code 
67: /usr/bin/maildrop -d delivery-test
Apr 15 17:01:29 stanchina courierlocal: 
id=00025C3C.60785549.1A68,from=,addr=: 
ERR: authdaemon: s_connect() failed: Permission denied
Apr 15 17:01:29 stanchina courierlocal: 
id=00025C3C.60785549.1A68,from=,addr=: 
Invalid user specified.
Apr 15 17:01:29 stanchina courierlocal: 
id=00025C3C.60785549.1A68,from=,addr=,status: 
deferred


I guess either dspam or maildrop are dropping privileges *before* querying 
the userdb.


I need to test by removing dspam from the equation and having Courier call 
maildrop directly, as per the standard Courier configuration, but that's 
not something I can do at my pleasure on the involved servers. I'll need to 
set up a test installation.


However, I question why this needs to be done in this way; when I saw the 
changelog entry and the bug report, I knew it would break something. While 
I agree that showing the password hash (and the cleartext password, if 
present) to normal users is not good, the rest of the info obtained through 
authtest is on the same level of sensitivity as "getent passwd" and that's 
available to normal users (I think it needs to). Also, as touched upon in 
#984810, I firmly believe this needs to be assessed in cooperation with 
upstream to evaluate pros and cons before implementing a fix.


--
Ciao, Flavio

Those who do not understand Unix are condemned to reinvent it, poorly.
-- Henry Spencer



Bug#987009: courier-authlib: the purported fix for #984810 breaks maildrop "delivery mode"

2021-04-15 Thread Markus Wanner

Control: tags -1 + moreinfo

On 15.04.21 16:20, Flavio Stanchina wrote:
The fix for #984810 breaks maildrop "delivery mode" because maildrop is 
no longer able to look up user details after dropping privileges (or at 
least this is what I think is happening, from my understanding of how 
"delivery mode" works).


Hm.. shouldn't the user running maildrop be part of the 'courier' group? 
 I don't think that's sufficient justification for making the 
information world-readable.


Regards

Markus



Bug#987009: courier-authlib: the purported fix for #984810 breaks maildrop "delivery mode"

2021-04-15 Thread Flavio Stanchina

Package: courier-authlib
Version: 0.66.4-9+deb9u1
Severity: critical

The fix for #984810 breaks maildrop "delivery mode" because maildrop is no 
longer able to look up user details after dropping privileges (or at least 
this is what I think is happening, from my understanding of how "delivery 
mode" works).


This is *really serious* as it completely breaks mail delivery on 
previously working system -- a production mail server, in my case.


Apr 15 14:59:18 stanchina dspam[13818]: Delivery agent returned exit code 
67: /usr/bin/maildrop -d delivery-test
Apr 15 14:59:18 stanchina courierlocal: 
id=00025C27.6078377A.3214,from=,addr=: 
ERR: authdaemon: s_connect() failed: Permission denied
Apr 15 14:59:18 stanchina courierlocal: 
id=00025C27.6078377A.3214,from=,addr=: 
Invalid user specified.
Apr 15 14:59:18 stanchina courierlocal: 
id=00025C27.6078377A.3214,from=,addr=,status: 
deferred


Best regards,
Flavio Stanchina