[Dovecot] checkpassword protocol
Hi,
I'm writing a checkpassword script in order to support our OTP token as a fallback for client certificate authentication. Here are two questions:
It seems to me that the username and the password will be delivered to my script both on file descriptor 3 and via the environment variables AUTH_USER and AUTH_PASSWORD. May I ignore file descriptor 3 and use the environment variables or may it happen that these variables will have differnet content from what is sent via fd 3?
There seems to be some undocumented interaction between dovecot and my script via file descriptor 4. Seems that whatever I write to fd 4 will show up in syslog (unless it contains newlines). Can I use this "feature" to send error messages from my script to dovecot? What data does dovecot expect on fd 4?
Peter
On 7.4.2013, at 14.30, dovecot.pkoch@dfgh.net wrote:
I'm writing a checkpassword script in order to support our OTP token as a fallback for client certificate authentication. Here are two questions:
- It seems to me that the username and the password will be delivered to my script both on file descriptor 3 and via the environment variables AUTH_USER and AUTH_PASSWORD. May I ignore file descriptor 3 and use the environment variables or may it happen that these variables will have differnet content from what is sent via fd 3?
Hmm. The AUTH_PASSWORD wasn't really an intentional addition .. but I guess it can stay there. Some 10 years ago that might not have been such a good idea since there were still some systems where process environment variables were readable to all users in the system, but I doubt there exist such systems anymore (at least where people would want to run Dovecot).
- There seems to be some undocumented interaction between dovecot and my script via file descriptor 4. Seems that whatever I write to fd 4 will show up in syslog (unless it contains newlines). Can I use this "feature" to send error messages from my script to dovecot? What data does dovecot expect on fd 4?
I'm not sure why that happens instead of a complete failure .. but you shouldn't be doing that. If you write to fd 2, it should also go to syslog, right? (If it doesn't, it's a bug.)
Hmm. The AUTH_PASSWORD wasn't really an intentional addition .. but I guess it can stay there. Some 10 years ago that might not have been such a good idea since there were still some systems where process environment variables were readable to all users in the system, but I doubt there exist such systems anymore (at least where people would want to run Dovecot).
Very optimistic assumption. Wouldn't it be safer to remove the password from the environment? Anyone using checkpassword should use FD 3 and 4 for this purpose. Environment variables and command line arguments are not safe to transport passwords.
Heiko
Heiko Schlichting Freie Universität Berlin heiko.schlichting@fu-berlin.de Zentraleinrichtung für Datenverarbeitung Telefon +49 30 838-54327 Fabeckstraße 32 Telefax +49 30 838454327 14195 Berlin
On 8.4.2013, at 10.00, Heiko Schlichting dovecot-l@FU-Berlin.DE wrote:
Hmm. The AUTH_PASSWORD wasn't really an intentional addition .. but I guess it can stay there. Some 10 years ago that might not have been such a good idea since there were still some systems where process environment variables were readable to all users in the system, but I doubt there exist such systems anymore (at least where people would want to run Dovecot).
Very optimistic assumption. Wouldn't it be safer to remove the password from the environment? Anyone using checkpassword should use FD 3 and 4 for this purpose. Environment variables and command line arguments are not safe to transport passwords.
All the OSes made the environment private 10-15 years ago. I think it's pretty safe to assume that older multiuser systems won't be running Dovecot with checkpassword backend.
But .. eh. I guess: http://hg.dovecot.org/dovecot-2.2/rev/9feb2986945c
Timo wrote:
All the OSes made the environment private 10-15 years ago. I think it's pretty safe to assume that older multiuser systems won't be running Dovecot with checkpassword backend.
The checkpassword interface is used in many different ways:
I found checkpassword the easiest way to implement authentication against FreeRADIUS. Using a perl script with
$input = IO::Handle->new_from_fd(3, "r");and
my $output = IO::Handle->new_from_fd(4, "w");and skipping the checkpassword-reply binary. This works fine on our server for many years now but every time when I read some related questions on the list, it seems that a more generic, not so crude interface would be a good idea for a future version of dovecot.
But .. eh. I guess: http://hg.dovecot.org/dovecot-2.2/rev/9feb2986945c
Great. Thank you.
Heiko
Heiko Schlichting Freie Universität Berlin heiko.schlichting@fu-berlin.de Zentraleinrichtung für Datenverarbeitung Telefon +49 30 838-54327 Fabeckstraße 32 Telefax +49 30 838454327 14195 Berlin
On 8.4.2013, at 13.42, Heiko Schlichting dovecot-l@fu-berlin.de wrote:
The checkpassword interface is used in many different ways:
I found checkpassword the easiest way to implement authentication against FreeRADIUS. Using a perl script with
$input = IO::Handle->new_from_fd(3, "r");
and
my $output = IO::Handle->new_from_fd(4, "w");
and skipping the checkpassword-reply binary. This works fine on our server for many years now but every time when I read some related questions on the list, it seems that a more generic, not so crude interface would be a good idea for a future version of dovecot.
For executing scripts/binaries I think checkpassword will stay the only way. Other than that, you could talk to Dovecot-auth via UNIX socket by using dict-proxy protocol with passdb/userdb dict. Although that way you'd need some way to keep your server running and it's not that easy yet to create a new Dovecot service without using libdovecot.
participants (3)
-
dovecot.pkoch＠dfgh.net
-
Heiko Schlichting
-
Timo Sirainen