When playing around with fail2ban, I was experiencing problems with the pop3d and imapd daemons. Turns out that fail2ban creates /etc/hosts.deny with mode 600, owner root, if the file didn't exist before. The cyrus daemons (running as user cyrus) drop incoming connections right away if the file exists but is not readable for them. This happens regardless of the file's content, it can even be empty. When changing the mode to 644, the file becomes readable and the crashes disappear. Reproducible: Always Steps to Reproduce: 1. create /etc/hosts.deny if file doesn't exist 2. chmod 600 /etc/hosts.deny; chown root.root /etc/hosts.deny 3. telnet [ip] 110 Actual Results: connection to pop3d is dropped immediately Expected Results: pop3d should accept the connection if IP is not banned in hosts.deny
I think that's more or less a problem (or bug) in fail2ban. Which specific version of fail2ban are you running? (Adding netmon@)
(In reply to comment #1) > I think that's more or less a problem (or bug) in fail2ban. Playing around with fail2ban revealed the bug for me, but it can be reproduced by carrying out the steps I stated in the initial post. I agree that fail2ban also has a bug - it should not create hosts.deny as 600. But that's not the point of the report I filed. In my opinion, it's a bug in cyrus' handling of the hosts.deny file. It hits whenever this file exists but cannot be read by the cyrus user.
(In reply to comment #2) > In my opinion, it's a bug in cyrus' handling of the hosts.deny file. It hits > whenever this file exists but cannot be read by the cyrus user. Please report this bug upstream then. There's not that much we can do about this.