dovecot-2.0: config: Removed auth sections completely for now.
dovecot at dovecot.org
dovecot at dovecot.org
Tue Sep 1 00:21:48 EEST 2009
details: http://hg.dovecot.org/dovecot-2.0/rev/cf27080f3fcf
changeset: 9846:cf27080f3fcf
user: Timo Sirainen <tss at iki.fi>
date: Mon Aug 31 17:21:37 2009 -0400
description:
config: Removed auth sections completely for now.
They might come back in some other more generic form.
diffstat:
5 files changed, 233 insertions(+), 354 deletions(-)
doc/example-config/conf.d/auth.conf | 443 +++++++++++++++++------------------
src/auth/auth-settings.c | 62 ----
src/auth/auth-settings.h | 10
src/auth/main.c | 7
src/config/config-parser.c | 65 -----
diffs (truncated from 739 to 300 lines):
diff -r f5dcc960ab7a -r cf27080f3fcf doc/example-config/conf.d/auth.conf
--- a/doc/example-config/conf.d/auth.conf Mon Aug 31 17:19:56 2009 -0400
+++ b/doc/example-config/conf.d/auth.conf Mon Aug 31 17:21:37 2009 -0400
@@ -76,230 +76,223 @@
# Number of seconds to delay before replying to failed authentications.
#auth_failure_delay = 2
-auth default {
- # Space separated list of wanted authentication mechanisms:
- # plain login digest-md5 cram-md5 ntlm rpa apop anonymous gssapi otp skey
- # gss-spnego
- # NOTE: See also disable_plaintext_auth setting.
- auth_mechanisms = plain
-
- #
- # Password database is used to verify user's password (and nothing more).
- # You can have multiple passdbs and userdbs. This is useful if you want to
- # allow both system users (/etc/passwd) and virtual users to login without
- # duplicating the system users into virtual database.
- #
- # <doc/wiki/PasswordDatabase.txt>
- #
- # By adding master=yes setting inside a passdb you make the passdb a list
- # of "master users", who can log in as anyone else. Unless you're using PAM,
- # you probably still want the destination user to be looked up from passdb
- # that it really exists. This can be done by adding pass=yes setting to the
- # master passdb. <doc/wiki/Authentication.MasterUsers.txt>
-
- # Users can be temporarily disabled by adding a passdb with deny=yes.
- # If the user is found from that database, authentication will fail.
- # The deny passdb should always be specified before others, so it gets
- # checked first. Here's an example:
-
- #passdb passwd-file {
- # File contains a list of usernames, one per line
- #args = /etc/dovecot.deny
- #deny = yes
- #}
-
- # PAM authentication. Preferred nowadays by most systems.
- # Note that PAM can only be used to verify if user's password is correct,
- # so it can't be used as userdb. If you don't want to use a separate user
- # database (passwd usually), you can use static userdb.
- # REMEMBER: You'll need /etc/pam.d/dovecot file created for PAM
- # authentication to actually work. <doc/wiki/PasswordDatabase.PAM.txt>
- passdb pam {
- # [session=yes] [setcred=yes] [failure_show_msg=yes] [max_requests=<n>]
- # [cache_key=<key>] [<service name>]
- #
- # session=yes makes Dovecot open and immediately close PAM session. Some
- # PAM plugins need this to work, such as pam_mkhomedir.
- #
- # setcred=yes makes Dovecot establish PAM credentials if some PAM plugins
- # need that. They aren't ever deleted though, so this isn't enabled by
- # default.
- #
- # max_requests specifies how many PAM lookups to do in one process before
- # recreating the process. The default is 100, because many PAM plugins
- # leak memory.
- #
- # cache_key can be used to enable authentication caching for PAM
- # (auth_cache_size also needs to be set). It isn't enabled by default
- # because PAM modules can do all kinds of checks besides checking password,
- # such as checking IP address. Dovecot can't know about these checks
- # without some help. cache_key is simply a list of variables (see
- # doc/wiki/Variables.txt) which must match for the cached data to be used.
- # Here are some examples:
- # %u - Username must match. Probably sufficient for most uses.
- # %u%r - Username and remote IP address must match.
- # %u%s - Username and service (ie. IMAP, POP3) must match.
- #
- # The service name can contain variables, for example %Ls expands to
- # pop3 or imap.
- #
- # Some examples:
- # args = session=yes %Ls
- # args = cache_key=%u dovecot
- #args = dovecot
- }
-
- # System users (NSS, /etc/passwd, or similiar)
- # In many systems nowadays this uses Name Service Switch, which is
- # configured in /etc/nsswitch.conf. <doc/wiki/AuthDatabase.Passwd.txt>
- #passdb passwd {
- # [blocking=yes] - See userdb passwd for explanation
- #args =
- #}
-
- # Shadow passwords for system users (NSS, /etc/shadow or similiar).
- # Deprecated by PAM nowadays.
- # <doc/wiki/PasswordDatabase.Shadow.txt>
- #passdb shadow {
- # [blocking=yes] - See userdb passwd for explanation
- #args =
- #}
-
- # PAM-like authentication for OpenBSD.
- # <doc/wiki/PasswordDatabase.BSDAuth.txt>
- #passdb bsdauth {
- # [cache_key=<key>] - See cache_key in PAM for explanation.
- #args =
- #}
-
- # passwd-like file with specified location
- # <doc/wiki/AuthDatabase.PasswdFile.txt>
- #passdb passwd-file {
- # [scheme=<default password scheme>] [username_format=<format>]
- # <Path for passwd-file>
- #args =
- #}
-
- # checkpassword executable authentication
- # NOTE: You will probably want to use "userdb prefetch" with this.
- # <doc/wiki/AuthDatabase.CheckPassword.txt>
- #passdb checkpassword {
- # Path for checkpassword binary
- #args =
- #}
-
- # SQL database <doc/wiki/AuthDatabase.SQL.txt>
- #passdb sql {
- # Path for SQL configuration file, see doc/dovecot-sql-example.conf
- #args =
- #}
-
- # LDAP database <doc/wiki/AuthDatabase.LDAP.txt>
- #passdb ldap {
- # Path for LDAP configuration file, see doc/dovecot-ldap-example.conf
- #args =
- #}
-
- # vpopmail authentication <doc/wiki/AuthDatabase.VPopMail.txt>
- #passdb vpopmail {
- # [cache_key=<key>] - See cache_key in PAM for explanation.
- # [quota_template=<template>] - %q expands to Maildir++ quota
- # (eg. quota_template=quota_rule=*:backend=%q)
- #args =
- #}
-
- #
- # User database specifies where mails are located and what user/group IDs
- # own them. For single-UID configuration use "static".
- #
- # <doc/wiki/UserDatabase.txt>
- #
-
- # "prefetch" user database means that the passdb already provided the
- # needed information and there's no need to do a separate userdb lookup.
- # This can be made to work with SQL and LDAP databases, see their example
- # configuration files for more information how to do it.
- # <doc/wiki/UserDatabase.Prefetch.txt>
- #userdb prefetch {
- #}
-
- # System users (NSS, /etc/passwd, or similiar). In many systems nowadays this
- # uses Name Service Switch, which is configured in /etc/nsswitch.conf.
- # <doc/wiki/AuthDatabase.Passwd.txt>
- userdb passwd {
- # [blocking=yes] - By default the lookups are done in the main dovecot-auth
- # process. This setting causes the lookups to be done in auth worker
- # proceses. Useful with remote NSS lookups that may block.
- # NOTE: Be sure to use this setting with nss_ldap or users might get
- # logged in as each others!
- #args =
- }
-
- # passwd-like file with specified location
- # <doc/wiki/AuthDatabase.PasswdFile.txt>
- #userdb passwd-file {
- # [username_format=<format>] <Path for passwd-file>
- #args =
- #}
-
- # checkpassword executable user database lookup
- # <doc/wiki/AuthDatabase.CheckPassword.txt>
- #userdb checkpassword {
- # Path for checkpassword binary
- #args =
- #}
-
- # static settings generated from template <doc/wiki/UserDatabase.Static.txt>
- #userdb static {
- # Template for the fields. Can return anything a userdb could normally
- # return. For example:
- #
- # args = uid=500 gid=500 home=/var/mail/%u
- #
- # If you use deliver, it needs to look up users only from the userdb. This
- # of course doesn't work with static because there is no list of users.
- # Normally static userdb handles this by doing a passdb lookup. This works
- # with most passdbs, with PAM being the most notable exception. If you do
- # the user verification another way, you can add allow_all_users=yes to
- # the args in which case the passdb lookup is skipped.
- #
- #args =
- #}
-
- # SQL database <doc/wiki/AuthDatabase.SQL.txt>
- #userdb sql {
- # Path for SQL configuration file, see doc/dovecot-sql-example.conf
- #args =
- #}
-
- # LDAP database <doc/wiki/AuthDatabase.LDAP.txt>
- #userdb ldap {
- # Path for LDAP configuration file, see doc/dovecot-ldap-example.conf
- #args =
- #}
-
- # vpopmail <doc/wiki/AuthDatabase.VPopMail.txt>
- #userdb vpopmail {
- #}
-
- # Require a valid SSL client certificate or the authentication fails.
- #auth_ssl_require_client_cert = no
-
- # Take the username from client's SSL certificate, using
- # X509_NAME_get_text_by_NID() which returns the subject's DN's
- # CommonName.
- #auth_ssl_username_from_cert = no
+# Require a valid SSL client certificate or the authentication fails.
+#auth_ssl_require_client_cert = no
+
+# Take the username from client's SSL certificate, using
+# X509_NAME_get_text_by_NID() which returns the subject's DN's
+# CommonName.
+#auth_ssl_username_from_cert = no
+
+# Space separated list of wanted authentication mechanisms:
+# plain login digest-md5 cram-md5 ntlm rpa apop anonymous gssapi otp skey
+# gss-spnego
+# NOTE: See also disable_plaintext_auth setting.
+auth_mechanisms = plain
+
+##
+## Password databases
+##
+
+#
+# Password database is used to verify user's password (and nothing more).
+# You can have multiple passdbs and userdbs. This is useful if you want to
+# allow both system users (/etc/passwd) and virtual users to login without
+# duplicating the system users into virtual database.
+#
+# <doc/wiki/PasswordDatabase.txt>
+#
+# By adding master=yes setting inside a passdb you make the passdb a list
+# of "master users", who can log in as anyone else. Unless you're using PAM,
+# you probably still want the destination user to be looked up from passdb
+# that it really exists. This can be done by adding pass=yes setting to the
+# master passdb. <doc/wiki/Authentication.MasterUsers.txt>
+
+# Users can be temporarily disabled by adding a passdb with deny=yes.
+# If the user is found from that database, authentication will fail.
+# The deny passdb should always be specified before others, so it gets
+# checked first. Here's an example:
+
+#passdb passwd-file {
+ # File contains a list of usernames, one per line
+ #args = /etc/dovecot.deny
+ #deny = yes
+#}
+
+# PAM authentication. Preferred nowadays by most systems.
+# Note that PAM can only be used to verify if user's password is correct,
+# so it can't be used as userdb. If you don't want to use a separate user
+# database (passwd usually), you can use static userdb.
+# REMEMBER: You'll need /etc/pam.d/dovecot file created for PAM
+# authentication to actually work. <doc/wiki/PasswordDatabase.PAM.txt>
+passdb pam {
+ # [session=yes] [setcred=yes] [failure_show_msg=yes] [max_requests=<n>]
+ # [cache_key=<key>] [<service name>]
+ #
+ # session=yes makes Dovecot open and immediately close PAM session. Some
+ # PAM plugins need this to work, such as pam_mkhomedir.
+ #
+ # setcred=yes makes Dovecot establish PAM credentials if some PAM plugins
+ # need that. They aren't ever deleted though, so this isn't enabled by
+ # default.
+ #
+ # max_requests specifies how many PAM lookups to do in one process before
+ # recreating the process. The default is 100, because many PAM plugins
+ # leak memory.
+ #
+ # cache_key can be used to enable authentication caching for PAM
+ # (auth_cache_size also needs to be set). It isn't enabled by default
+ # because PAM modules can do all kinds of checks besides checking password,
+ # such as checking IP address. Dovecot can't know about these checks
+ # without some help. cache_key is simply a list of variables (see
+ # doc/wiki/Variables.txt) which must match for the cached data to be used.
+ # Here are some examples:
+ # %u - Username must match. Probably sufficient for most uses.
+ # %u%r - Username and remote IP address must match.
+ # %u%s - Username and service (ie. IMAP, POP3) must match.
+ #
+ # The service name can contain variables, for example %Ls expands to
+ # pop3 or imap.
+ #
+ # Some examples:
+ # args = session=yes %Ls
More information about the dovecot-cvs
mailing list