[Dovecot] Allow_nets + MySQL failing when using range notation
Hello all,
I am testing my dovecot installation in order to restrict access via POP3 for IPs outside my network. I have read and understood the instructions in the wiki and I have reached a configuration that works ONLY when single IPs are listed in allow_nets but not when ranges in the notation x.x.x.x/y are listed. Some examples should be more explanatory. I am using 1.0.rc15 patched as for last week as distributed in Debian etch.
First of all, everything related to this is stored in a MySQL database, here is my password query:
password_query = SELECT u.password as password, t.allow_nets as allow_nets FROM users u, access_type t WHERE u.ID_access_type = t.ID_access and ( t.%Ls = 1 ) and u.mail = '%u'
This one should validate all mail addresses when the protocol used is marked as 1 in table access_type and when the allow_nets value in this same table contains the IP used for the access request. The, if access_type looks like:
ID_access pop3 imap allow_nets 3 0 1 10.34.128.0/23, 10.34.133.0/24, 192.168.0.0/24
users with ID_access=3 fail to login by either pop3 (normal, value is 0) or imap. Here is the corresponding excerpt from dovecot.log:
dovecot: 2008-03-31 11:29:04 Info: auth-worker(default): sql(user@domain.com,10.34.133.104): query: SELECT u.password as password, t.allow_nets as allow_nets FROM users u, access_type t WHERE u.ID_access_type = t.ID_access and ( t.imap = 1 ) and u.mail = 'user@domain.com' dovecot: 2008-03-31 11:26:39 Info: auth-worker(default): auth(user@domain.com,10.34.133.104): allow_nets: Matching for network 192.168.0.0/24 dovecot: 2008-03-31 11:26:39 Info: auth-worker(default): auth(user@domain.com,10.34.133.104): allow_nets: Matching for network 10.34.128.0/23 dovecot: 2008-03-31 11:26:39 Info: auth-worker(default): auth(user@domain.com,10.34.133.104): allow_nets: Matching for network 10.34.133.0/23 dovecot: 2008-03-31 11:26:39 Info: auth-worker(default): passdb(user@domain.com,10.34.133.104): allow_nets check failed: IP not in allowed networks
but if it looks like
ID_access pop3 imap allow_nets 3 0 1 10.34.133.105, 10.34.133.104
then access is allowed by IMAP
dovecot: 2008-03-31 11:34:01 Info: auth-worker(default):
sql(user@domain.com,10.34.133.104): query: SELECT u.password as
password, t.allow_nets as allow_nets FROM users u, access_type t WHERE
u.ID_access_type = t.ID_access and ( t.imap = 1 ) and u.mail =
'user@domain.com'
dovecot: 2008-03-31 11:34:01 Info: auth-worker(default):
auth(user@domain.com,10.34.133.104): allow_nets: Matching for network
10.34.133.105
dovecot: 2008-03-31 11:34:01 Info: auth-worker(default):
auth(user@domain.com,10.34.133.104): allow_nets: Matching for network
10.34.133.104
dovecot: 2008-03-31 11:34:01 Info: auth(default): client out: OK
1 user=user@domain.com
while POP3 still disallowed as expected:
dovecot: 2008-03-31 11:34:25 Info: auth-worker(default): sql(user@domain.com,10.34.133.104): query: SELECT u.password as password, t.allow_nets as allow_nets FROM users u, access_type t WHERE u.ID_access_type = t.ID_access and ( t.pop3 = 1 ) and u.mail = 'user@domain.com' dovecot: 2008-03-31 11:34:25 Info: auth-worker(default): sql(user@domain.com,10.34.133.104): unknown user
So, is there a bug related to the IP class notation or am I doing something wrong? I have tried to leave a single class (10.34.133.0/24), to explicitly erase any spaces after the commas, but nothing of these worked. Also, note that using 0.0.0.0/0 behaves as expected, this is, access for any IP is allowed.
Thanks in advance,
Javier
On Mon, 2008-03-31 at 12:56 +0200, Javier García wrote:
Hello all,
I am testing my dovecot installation in order to restrict access via POP3 for IPs outside my network. I have read and understood the instructions in the wiki and I have reached a configuration that works ONLY when single IPs are listed in allow_nets but not when ranges in the notation x.x.x.x/y are listed. Some examples should be more explanatory. I am using 1.0.rc15 patched as for last week as distributed in Debian etch.
I don't see any obvious entries in ChangeLog related to this, but it seems to work correctly in v1.0.13 and v1.1.rc4, so maybe it was just broken in rc15.
Hello,
Thanks Timo for the response. I will then ask the Debian package maintainers on this specific issue.
Regards, Javier
Timo Sirainen escribió:
On Mon, 2008-03-31 at 12:56 +0200, Javier García wrote:
Hello all,
I am testing my dovecot installation in order to restrict access via POP3 for IPs outside my network. I have read and understood the instructions in the wiki and I have reached a configuration that works ONLY when single IPs are listed in allow_nets but not when ranges in the notation x.x.x.x/y are listed. Some examples should be more explanatory. I am using 1.0.rc15 patched as for last week as distributed in Debian etch.
I don't see any obvious entries in ChangeLog related to this, but it seems to work correctly in v1.0.13 and v1.1.rc4, so maybe it was just broken in rc15.
Hello again,
I am afraid that I must come back with this issue. Following advice from the Debian package maintainers, I installed a backported 1.0.13 version which keeps behaving wrongly. To be more specific:
My software version is now: prisni:/# dovecot --version 1.0.13
My debian packages, just to be redundant: prisni:/# dpkg -l dovecot* ii dovecot-common 1.0.13-1~bpo40+1 secure mail server that supports mbox and maildir mailboxes ii dovecot-imapd 1.0.13-1~bpo40+1 secure IMAP server that supports mbox and maildir mailboxes ii dovecot-pop3d 1.0.13-1~bpo40+1 secure POP3 server that supports mbox and maildir mailboxes
A login attempt from one IP in the allowed network... prisni:/etc/postfix# telnet 10.34.133.64 143 Trying 10.34.133.64... Connected to prisni.tiscali.red. Escape character is '^]'.
- OK Bienvenido a prisni.inicia.es. 001 login user@domain password 001 NO Authentication failed. 002 logout
- BYE Logging out 002 OK Logout completed. Connection closed by foreign host.
... fails :-(
dovecot: 2008-05-07 17:58:34 Info: auth-worker(default):
sql(user@domain,10.34.133.64): query: select pd.contrasena as password,
pd.allow_nets from v_permisos_direcciones pd where ( pd.imap = 1 ) and
pd.correo = 'user@domain'
dovecot: 2008-05-07 17:58:34 Info: auth-worker(default):
auth(user@domain,10.34.133.64): allow_nets: Matching for network
10.34.133.0/24
dovecot: 2008-05-07 17:58:34 Info: auth-worker(default):
passdb(user@domain,10.34.133.64): allow_nets check failed: IP not in
allowed networks
dovecot: 2008-05-07 17:58:35 Info: auth(default): client out: FAIL
1 user=user@domain
dovecot: 2008-05-07 17:58:37 Info: imap-login: user=user@domain,
method=PLAIN, rip=10.34.133.64, lip=10.34.133.64, secured: Aborted login
(1 authentication attempts)
I wonder if this option is rare enough to this issue have remained undiscovered through versions... Is there anyone out there using allow_nets in the same way as I am trying to do? Note that using a list single IPs has always worked in my environment.
Thanks in advance, Javier
Javier García escribió:
Hello,
Thanks Timo for the response. I will then ask the Debian package maintainers on this specific issue.
Regards, Javier
Timo Sirainen escribió:
On Mon, 2008-03-31 at 12:56 +0200, Javier García wrote:
Hello all,
I am testing my dovecot installation in order to restrict access via POP3 for IPs outside my network. I have read and understood the instructions in the wiki and I have reached a configuration that works ONLY when single IPs are listed in allow_nets but not when ranges in the notation x.x.x.x/y are listed. Some examples should be more explanatory. I am using 1.0.rc15 patched as for last week as distributed in Debian etch.
I don't see any obvious entries in ChangeLog related to this, but it seems to work correctly in v1.0.13 and v1.1.rc4, so maybe it was just broken in rc15.
On Wed, 2008-05-07 at 18:15 +0200, Javier García wrote:
I am afraid that I must come back with this issue. Following advice from the Debian package maintainers, I installed a backported 1.0.13 version which keeps behaving wrongly. To be more specific:
Do you use x86 or something else? Just wondering if this could be because of some endianess issue.
I wonder if this option is rare enough to this issue have remained undiscovered through versions...
Could be, but it worked in my tests.. I guess it's also possible I messed up my tests somehow.
x86, mmm..., in fact, I am testing on a sparc box, I will retry on a x86 system as my production environment is x86. I cannot guess the effect of an architecture change, but maybe some library implementations might matter... I'll let you know. In the meantime, some more details on the actual installation:
prisni:~# uname -a Linux prisni 2.6.18-6-sparc64 #1 Tue Feb 12 21:51:30 UTC 2008 sparc64 GNU/Linux
The installed packages along with dovecot are, in short, postfix, horde, apache2 and mysql.
PS: While awaiting for moderator approval (this message was originally too big) I have made a small test on my production environment,
polifemo:~# uname -a Linux polifemo 2.6.18-5-686 #1 SMP Mon Dec 24 16:41:07 UTC 2007 i686 GNU/Linux
which seems to work. So we could probably restrict the issue to linux on sparc... quite a special scenario, in my opinion.
As this latest test is just preliminary, I'll let you know about further results.
Regards, Javier
Timo Sirainen escribió:
On Wed, 2008-05-07 at 18:15 +0200, Javier García wrote:
I am afraid that I must come back with this issue. Following advice from the Debian package maintainers, I installed a backported 1.0.13 version which keeps behaving wrongly. To be more specific:
Do you use x86 or something else? Just wondering if this could be because of some endianess issue.
I wonder if this option is rare enough to this issue have remained undiscovered through versions...
Could be, but it worked in my tests.. I guess it's also possible I messed up my tests somehow.
Hello,
Just a couple of lines to definitely confirm that the issue is present *only* on the sparc version of Debian while on a box equipped with an Intel Pentium processor everything works as expected. Thanks a lot for your support.
Javier
Javier García escribió:
x86, mmm..., in fact, I am testing on a sparc box, I will retry on a x86 system as my production environment is x86. I cannot guess the effect of an architecture change, but maybe some library implementations might matter... I'll let you know. In the meantime, some more details on the actual installation:
prisni:~# uname -a Linux prisni 2.6.18-6-sparc64 #1 Tue Feb 12 21:51:30 UTC 2008 sparc64 GNU/Linux
The installed packages along with dovecot are, in short, postfix, horde, apache2 and mysql.
PS: While awaiting for moderator approval (this message was originally too big) I have made a small test on my production environment,
polifemo:~# uname -a Linux polifemo 2.6.18-5-686 #1 SMP Mon Dec 24 16:41:07 UTC 2007 i686 GNU/Linux
which seems to work. So we could probably restrict the issue to linux on sparc... quite a special scenario, in my opinion.
As this latest test is just preliminary, I'll let you know about further results.
Regards, Javier
Timo Sirainen escribió:
On Wed, 2008-05-07 at 18:15 +0200, Javier García wrote:
I am afraid that I must come back with this issue. Following advice from the Debian package maintainers, I installed a backported 1.0.13 version which keeps behaving wrongly. To be more specific:
Do you use x86 or something else? Just wondering if this could be because of some endianess issue.
I wonder if this option is rare enough to this issue have remained undiscovered through versions...
Could be, but it worked in my tests.. I guess it's also possible I messed up my tests somehow.
On Wed, 2008-05-14 at 18:32 +0200, Javier García wrote:
Hello,
Just a couple of lines to definitely confirm that the issue is present *only* on the sparc version of Debian while on a box equipped with an Intel Pentium processor everything works as expected. Thanks a lot for your support.
- 2008-05-15 07:36, Timo Sirainen wrote:
Uploaded as 1.0.13-5, will hit unstable at the next dinstall run.
Thanks for the patch, Timo.
-- Fabio Tranchitella http://www.kobold.it Free Software Developer and Consultant http://www.tranchitella.it
1024D/7F961564, fpr 5465 6E69 E559 6466 BF3D 9F01 2BF8 EE2B 7F96 1564
participants (3)
-
Fabio Tranchitella
-
Javier García
-
Timo Sirainen