dovecot - Apr 2015 - Disabling of userdb/passdb modules using config statements

Hola,

Debian (and possibly other distros) use the /etc/dovecot/conf.d/* setup
where default config files are stuffed and then one can just add a
99-myconfig.conf et voila, variables are overruled.

This allows the distro to supply updates to the files at package upgrade
time without any/much user intervention.

The problem (for me ;) is that the system comes provided with:

auth-system.conf.ext containing:

passdb {
    driver = pam
}
userdb {
    driver = passwd
}

Hence pam & /etc/passwd based are always enabled.
This while I don't have any local users.

Replication seems to then always pick up the local users, which are
vmail + nobody (65536).

doveadm user '*' thus reports vmail, nobody + virtual users

Setting:
first_valid_uid = 5000
last_valid_uid = 5000

only keeps vmail in there, but apparently some module (guess
replication) is still able to figure out that 'nobody' exists:

Apr 10 09:48:25 mail dovecot: doveadm(IPADDR,nobody): Error: Mail access
for users with UID 65534 not permitted (see first_valid_uid in config
file, uid from userdb lookup).
Apr 10 09:48:25 mail dovecot: doveadm(IPADDR,nobody): Error:
dsync-server: User init failed
Apr 10 09:49:38 mail dovecot: doveadm(nobody): Error: sync: Failed to
start remote dsync-server command: Remote exit_code=75

and on the other side:
Apr 10 09:54:38 mail dovecot: doveadm(nobody): Error: sync: Unknown user
in remote

This can be resolved by commenting out the entries in
auth-system.conf.ext but then I'll have to do that again at package
upgrade time.

Hence, would it be a cool option to be able (in the 99-myconfig.conf)
file to put:

passdb {
    driver = pam
    enabled = false
}
userdb {
    driver = passwd
    enabled = false
}

And thereby disabling those modules completely? Thus avoiding upgrade
conflicts etc.

Greets,
 Jeroen

On 04/10/2015 05:59 AM, Jeroen Massar wrote:
>
> This can be resolved by commenting out the entries in
> auth-system.conf.ext but then I'll have to do that again at package
> upgrade time.
Comment out the !include auth-system.conf.ext line in 10-auth.conf.
>
> Hence, would it be a cool option to be able (in the 99-myconfig.conf)
> file to put:
Actually you mean local.conf. See the master dovecont.conf file, it's 
included last.
>
> passdb {
>      driver = pam
>      enabled = false
> }
> userdb {
>      driver = passwd
>      enabled = false
> }
>
> And thereby disabling those modules completely? Thus avoiding upgrade
> conflicts etc.
That's an interesting idea actually. My first thought is that it could 
be helpful to use *named* passdb / userdb sections to facilitate this.
>
> Greets,
>   Jeroen

On 2015-04-10 12:16, Gedalya wrote:
> On 04/10/2015 05:59 AM, Jeroen Massar wrote:
>>
>> This can be resolved by commenting out the entries in
>> auth-system.conf.ext but then I'll have to do that again at package
>> upgrade time.
> 
> Comment out the !include auth-system.conf.ext line in 10-auth.conf.
Though indeed simpler than commenting out multiple lines, that file also
gets replaced by a package upgrade.

Hence does not solve the 'can just upgrade silently' issue.
>> Hence, would it be a cool option to be able (in the 99-myconfig.conf)
>> file to put:
> Actually you mean local.conf. See the master dovecont.conf file, it's
> included last.
Only when it exists, one can use both.

from dovecot.conf:
8<-------------
# Most of the actual configuration gets included below. The filenames are
# first sorted by their ASCII value and parsed in that order. The
00-prefixes
# in filenames are intended to make it easier to understand the ordering.
!include conf.d/*.conf

# A config file can also tried to be included without giving an error if
# it's not found:
!include_try local.conf
--------------------------->8

Both conf.d/99-myconfig.conf and local.conf can work for this.

I prefer 99- as that is what other daemons also use.
>>
>> passdb {
>>      driver = pam
>>      enabled = false
>> }
>> userdb {
>>      driver = passwd
>>      enabled = false
>> }
>>
>> And thereby disabling those modules completely? Thus avoiding upgrade
>> conflicts etc.
> That's an interesting idea actually. My first thought is that it could
> be helpful to use *named* passdb / userdb sections to facilitate this.
That would require a default system, which now works out of the box with
pam/etc to be properly named and then renamed...

Greets,
 Jeroen

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On Fri, 10 Apr 2015, Jeroen Massar wrote:
> Debian (and possibly other distros) use the /etc/dovecot/conf.d/* setup
> where default config files are stuffed and then one can just add a
> 99-myconfig.conf et voila, variables are overruled.
> This allows the distro to supply updates to the files at package upgrade
> time without any/much user intervention.
>
> The problem (for me ;) is that the system comes provided with:
>
> auth-system.conf.ext containing:
>
> passdb {
>    driver = pam
> }
> userdb {
>    driver = passwd
> }
>
> Hence pam & /etc/passwd based are always enabled.
> This while I don't have any local users.
Isn't that a packaging problem then? Debian should use DEBCONF to ask you 
while installation, which db to enable by default. You should file a bug 
with Debian to let the admin choose, which (if at all) db to enable by 
default. There are no config files installed by Dovecot, if compiled by 
source.
>
> Replication seems to then always pick up the local users, which are
> vmail + nobody (65536).
>
> doveadm user '*' thus reports vmail, nobody + virtual users
>
> Setting:
> first_valid_uid = 5000
> last_valid_uid = 5000
>
> only keeps vmail in there, but apparently some module (guess
> replication) is still able to figure out that 'nobody' exists:
>
> Apr 10 09:48:25 mail dovecot: doveadm(IPADDR,nobody): Error: Mail access
> for users with UID 65534 not permitted (see first_valid_uid in config
> file, uid from userdb lookup).
> Apr 10 09:48:25 mail dovecot: doveadm(IPADDR,nobody): Error:
> dsync-server: User init failed
> Apr 10 09:49:38 mail dovecot: doveadm(nobody): Error: sync: Failed to
> start remote dsync-server command: Remote exit_code=75
>
> and on the other side:
> Apr 10 09:54:38 mail dovecot: doveadm(nobody): Error: sync: Unknown user
> in remote
>
> This can be resolved by commenting out the entries in
> auth-system.conf.ext but then I'll have to do that again at package
> upgrade time.
>
> Hence, would it be a cool option to be able (in the 99-myconfig.conf)
> file to put:
>
> passdb {
>    driver = pam
>    enabled = false
> }
> userdb {
>    driver = passwd
>    enabled = false
> }
>
> And thereby disabling those modules completely? Thus avoiding upgrade
> conflicts etc.
>
> Greets,
> Jeroen
>
- -- 
Steffen Kaiser
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1

iQEVAwUBVSvDzHz1H7kL/d9rAQJybAgAyOmtGbDyp6nzR0IqK2RUTWTHtjkbcmrN
G6MNxMCzsByp7JCCKaKZy4Ec9//4ua5+29zwsF4f/EjdyxOtCdZkOA2TRuw3Zbns
nuECm4h03HsjkGIi216mMHP3z2QjqTuZNWFj0MppBuiBqSuNrNFfxQ0pac3xEeAo
IYnKl1Oq4SKfwr351iF94NSHzCbR7CJDe5Q7TqkK8OB7PuASFIbYX9R6CYZc1jsR
euLRHKssX7Brw44PkQGLjHEOBG8xWP4/cAVf4bApskSiW8q1IZWhMR7Z4rbUgxRY
3RInqI/rJ8azOjZWd8Us25eCJl3f30bFkdbmOlL6LlUkzPAjMPx/3A==MZqU
-----END PGP SIGNATURE-----