At 1AM +0200 on 1/02/13 you (Timo Sirainen) wrote:
On 1.2.2013, at 0.35, Ben Morrow ben@morrow.me.uk wrote:
I am running Dovecot with system users (userdb passwd), but some of those users don't have shell accounts on the IMAP server so their shell on that machine is set to /usr/sbin/nologin. Currently I am using maildirs and this is not a problem, but I am in the process of switching to dbox which means I will need a cronjob running 'doveadm purge -A'.
During testing I found that those users with a 'nologin' shell are not included in the list returned by the userdb iterator, and that the iterator doesn't honour the first/last_valid_uid settings. This inconsistency seems undesirable, so the attached patch
- makes lookup perform the same checks as iteration,
Hmmh. You could also just have them aliased to other users, so this wouldn't be necessary..
I don't understand what you mean. Alias them where?
- makes the 'nologin' check configurable,
- adds a new optional check that the user owns their home directory.
These settings are passwd-specific, so they would have to something like:
userdb { driver = passwd args = check-nologin=n check-home=y }
OK. New patch attached.
The last check was the one performed by qmail, and seems to me to be a more reliable 'is this a real user' check than a nologin shell.
It also performs disk I/O, slowing down the lookup.
Hmm. OK, I've left that part out: my real users are segregated by UID anyway, so all I really care about is getting rid of the nologin check. (I would be perfectly happy if the check were just removed altogether.)
If this patch is applied, the release notes for the next release should probably mention that system users with a 'nologin' shell will no longer be allowed to log in to IMAP until the 'auth_check_nologin' setting is changed from true to false.
The default will in any case be the same as it is now.
Well, yes; but authentication will now check for a nologin shell by default, which it didn't before, so the visible behaviour will have changed.
Also, there seem to be two first/last_valid_uid settings: first_valid_uid itself, which is honoured by the storage subsystem, and auth_first_valid_uid, which is honoured by the 'passwd' userdb. Is this intentional?
Nope, that's a bug. Fixed that in v2.2: http://hg.dovecot.org/dovecot-2.2/rev/18661d1d6ed0
Cool. Will that be backported to 2.1 at some point?
Ben