[Dovecot] Static list of users with passdb pam
Hi,
On my system, I want to provide imap access for some of the users listed in /etc/passwd. The list of users should be provided by me, and should just be a list in a text file. All the userdb options are static (uid, gid, home directory). Unfortunately, I cannot think of a way to configure Dovecot to do this. The closest I get is with:
passdb pam {} userdb passwd-file { args = /path/to/passwd-file }
However, the passwd-file is now more complex than it really needs to be, as it includes fields for password, uid, gid and home directory as well.
Is there some way to handle this? Or am I trying to do something stupid?
Thanks!
Koen
If you are using pam already, why not add to /etc/pam.d/dovecot something like:
auth required pam_listfile.so onerr=fail item=user sense=allow file=/etc/dovecot/allowed_users
The syntax may not be quite correct as this is off the top of my head and I havent tested it, but we do something very similar with other pam authentications, such as from vsftpd, to restrict user access.
Regards, Rob
On Fri, 2008-01-18 at 10:04 +0100, Koen Vermeer wrote:
Hi,
On my system, I want to provide imap access for some of the users listed in /etc/passwd. The list of users should be provided by me, and should just be a list in a text file. All the userdb options are static (uid, gid, home directory). Unfortunately, I cannot think of a way to configure Dovecot to do this. The closest I get is with:
passdb pam {} userdb passwd-file { args = /path/to/passwd-file }
However, the passwd-file is now more complex than it really needs to be, as it includes fields for password, uid, gid and home directory as well.
Is there some way to handle this? Or am I trying to do something stupid?
Thanks!
Koen
Please consider the environment before printing this email.
GAME Stores Group Ltd has been awarded Retailer of the Year at the 2006 Golden Joystick Awards and 'Thames Valley Business Award' for Outstanding Employer of Choice 2006.
This e-mail and any files transmitted with it are confidential and intended solely for the use of the individual or entity to whom they are addressed. If you have received this e-mail in error please notify the system manager at:
mailto:postmaster@game.co.uk
The recipient acknowledges that the transmissions made via the Internet can be corrupted and therefore THE GAME GROUP PLC and any of its subsidiaries do not give any warranty as to the quality or accuracy of any information contained in the message or assume any liability for it or for its transmission, reception or storage.
This footnote also confirms that this e-mail message has been swept by anti-virus software for the presence of computer viruses.
http://www.game.co.uk http://www.gamegroup.plc.uk
Registered Number: 1937170 Registered Office: Unity House, Telford Road, Basingstoke, Hampshire. RG21 6YJ Registered in England and Wales.
Thanks for the pointer. I guess I need to change the userdb entry as well. I now have
userdb static { args = uid=xxx gid=xxx home=whatever allow_all_users=yes }
which seems to do what I want. I'll test some more, but I guess this works fine. Thanks again!
Best, Koen
On Fri, 2008-01-18 at 09:25 +0000, Rob Coward wrote:
If you are using pam already, why not add to /etc/pam.d/dovecot something like:
auth required pam_listfile.so onerr=fail item=user sense=allow file=/etc/dovecot/allowed_users
The syntax may not be quite correct as this is off the top of my head and I havent tested it, but we do something very similar with other pam authentications, such as from vsftpd, to restrict user access.
Regards, Rob
On Fri, 2008-01-18 at 10:04 +0100, Koen Vermeer wrote:
Hi,
On my system, I want to provide imap access for some of the users listed in /etc/passwd. The list of users should be provided by me, and should just be a list in a text file. All the userdb options are static (uid, gid, home directory). Unfortunately, I cannot think of a way to configure Dovecot to do this. The closest I get is with:
passdb pam {} userdb passwd-file { args = /path/to/passwd-file }
However, the passwd-file is now more complex than it really needs to be, as it includes fields for password, uid, gid and home directory as well.
Is there some way to handle this? Or am I trying to do something stupid?
Thanks!
Koen
Please consider the environment before printing this email.
GAME Stores Group Ltd has been awarded Retailer of the Year at the 2006 Golden Joystick Awards and 'Thames Valley Business Award' for Outstanding Employer of Choice 2006.
This e-mail and any files transmitted with it are confidential and intended solely for the use of the individual or entity to whom they are addressed. If you have received this e-mail in error please notify the system manager at:
mailto:postmaster@game.co.uk
The recipient acknowledges that the transmissions made via the Internet can be corrupted and therefore THE GAME GROUP PLC and any of its subsidiaries do not give any warranty as to the quality or accuracy of any information contained in the message or assume any liability for it or for its transmission, reception or storage.
This footnote also confirms that this e-mail message has been swept by anti-virus software for the presence of computer viruses.
http://www.game.co.uk http://www.gamegroup.plc.uk
Registered Number: 1937170 Registered Office: Unity House, Telford Road, Basingstoke, Hampshire. RG21 6YJ Registered in England and Wales.
While this solution works fine for imap purposes, I cannot get this to work the way I want with postfix and deliver. What I would like to have is that if a message is sent to a non-existing user, it gets rejected. Instead, I can see in the logs that deliver notices that the mailbox doesn't exist (msgid=1201601833.5315.23.camel@localhost: Couldn't open mailbox {}: Mailbox doesn't exist: {}), but it also reports that it delivered it to the INBOX (msgid=1201601833.5315.23.camel@localhost: saved mail to INBOX) and postfix reports 'status=sent (delivered via dovecot service). I tried several other options (without '-e' the dovecot line in master.cf - same result; without allow_all_users=yes - dovecot-auth complains that: passdb doesn't support lookups, can't verify user's existence).
In postfix, I have in main.cf:
virtual_mailbox_domains = domain.net virtual_alias_maps = hash:/srv/mail/aliases virtual_transport = dovecot dovecot_destination_recipient_limit = 1
master.cf contains:
dovecot unix - n n - - pipe flags=DRhu user=vmail:vmail argv=/usr/lib/dovecot/deliver -f ${sender} -d ${user} -n -m {$extension} -e
In aliases, I have a mapping from, for example, k.vermeer@domain.net to koen:
k.vermeer@domain.net koen
dovecot -n shows: # 1.0.10: /etc/dovecot/dovecot.conf log_timestamp: %Y-%m-%d %H:%M:%S protocols: imaps login_dir: /var/run/dovecot/login login_executable: /usr/lib/dovecot/imap-login mail_extra_groups: mail mail_location: maildir:/srv/mail/%u/mail mail_debug: yes auth default: passdb: driver: pam userdb: driver: static args: uid=vmail gid=vmail home=/srv/mail/%u allow_all_users=yes socket: type: listen client: path: /var/spool/postfix/private/auth mode: 432 user: postfix group: postfix master: path: /var/run/dovecot/auth-master mode: 384 user: vmail group: vmail
I have setup pam with
auth required pam_listfile.so onerr=fail item=user sense=allow file=/srv/mail/mailusers
Best, Koen
On Fri, 2008-01-18 at 10:46 +0100, Koen Vermeer wrote:
Thanks for the pointer. I guess I need to change the userdb entry as well. I now have
userdb static { args = uid=xxx gid=xxx home=whatever allow_all_users=yes }
which seems to do what I want. I'll test some more, but I guess this works fine. Thanks again!
Best, Koen
On Fri, 2008-01-18 at 09:25 +0000, Rob Coward wrote:
If you are using pam already, why not add to /etc/pam.d/dovecot something like:
auth required pam_listfile.so onerr=fail item=user sense=allow file=/etc/dovecot/allowed_users
The syntax may not be quite correct as this is off the top of my head and I havent tested it, but we do something very similar with other pam authentications, such as from vsftpd, to restrict user access.
Regards, Rob
On Fri, 2008-01-18 at 10:04 +0100, Koen Vermeer wrote:
Hi,
On my system, I want to provide imap access for some of the users listed in /etc/passwd. The list of users should be provided by me, and should just be a list in a text file. All the userdb options are static (uid, gid, home directory). Unfortunately, I cannot think of a way to configure Dovecot to do this. The closest I get is with:
passdb pam {} userdb passwd-file { args = /path/to/passwd-file }
However, the passwd-file is now more complex than it really needs to be, as it includes fields for password, uid, gid and home directory as well.
Is there some way to handle this? Or am I trying to do something stupid?
Thanks!
Koen
Please consider the environment before printing this email.
GAME Stores Group Ltd has been awarded Retailer of the Year at the 2006 Golden Joystick Awards and 'Thames Valley Business Award' for Outstanding Employer of Choice 2006.
This e-mail and any files transmitted with it are confidential and intended solely for the use of the individual or entity to whom they are addressed. If you have received this e-mail in error please notify the system manager at:
mailto:postmaster@game.co.uk
The recipient acknowledges that the transmissions made via the Internet can be corrupted and therefore THE GAME GROUP PLC and any of its subsidiaries do not give any warranty as to the quality or accuracy of any information contained in the message or assume any liability for it or for its transmission, reception or storage.
This footnote also confirms that this e-mail message has been swept by anti-virus software for the presence of computer viruses.
http://www.game.co.uk http://www.gamegroup.plc.uk
Registered Number: 1937170 Registered Office: Unity House, Telford Road, Basingstoke, Hampshire. RG21 6YJ Registered in England and Wales.
On Tue, 2008-01-29 at 11:48 +0100, Koen Vermeer wrote:
While this solution works fine for imap purposes, I cannot get this to work the way I want with postfix and deliver. What I would like to have is that if a message is sent to a non-existing user, it gets rejected. Instead, I can see in the logs that deliver notices that the mailbox doesn't exist (msgid=1201601833.5315.23.camel@localhost: Couldn't open mailbox {}: Mailbox doesn't exist: {}), but it also reports that it delivered it to the INBOX (msgid=1201601833.5315.23.camel@localhost: saved mail to INBOX) and postfix reports 'status=sent (delivered via dovecot service). I tried several other options (without '-e' the dovecot line in master.cf - same result; without allow_all_users=yes - dovecot-auth complains that: passdb doesn't support lookups, can't verify user's existence).
Either verify the user's existence in Postfix (I don't really know how, more of a postfix-users list question), or use something else than passdb pam + userdb static. There's just no way to ask from PAM if a user exists or not, and userdb static gives the same values for everyone so it can't verify users' existence either.
On Thu, 2008-01-31 at 16:33 +0200, Timo Sirainen wrote:
Either verify the user's existence in Postfix (I don't really know how, more of a postfix-users list question), or use something else than passdb pam + userdb static. There's just no way to ask from PAM if a user exists or not, and userdb static gives the same values for everyone so it can't verify users' existence either.
In that case: Is there any chance of a future user database that is like a stripped-down passwd-file? The password field is never used for a userdb, gecos and shell isn't used either, and the other fields are only required if they are not fixed. Then, in the configuration file, the uid, gid and home can be set to a fixed or default value (as can now be done with passwd).
For now, I just fill the passwd-file like this: [username1]::uid:gid::/path/[username1]:: [username2]::uid:gid::/path/[username2]:: which contains a lot of static data in each entry.
Best, Koen
On Thu, 2008-02-07 at 15:58 +0100, Koen Vermeer wrote:
In that case: Is there any chance of a future user database that is like a stripped-down passwd-file?
Seems like unnecessary bloat. You could do this yourself by keeping the database in a stripped down file and then running a script after each change to build a full passwd-file.
participants (3)
-
Koen Vermeer
-
Rob Coward
-
Timo Sirainen