On Sun, 2008-05-25 at 10:21 +0300, Gelu G. Lupas wrote:

Hello. I'm having the following problem with dovecot 1.0.12 and above, on a FreeBSD 7.0 system - I'm trying to run pop3-login from inetd and I keep getting this error after authentication:

May 25 09:46:19 charlie dovecot: POP3(gelu): /libexec/ld-elf.so.1: environment corrupt; missing value for no-nuls oe-ns-eoh

The problem persists if I uncomment the lines with no-nuls oe-ns-eoh in dovecot.conf.

"uncomment"? What if you comment them? Does it at least change the error message? I've looked at this error before, but I don't see any obvious reason why it would happen.

Does it work if you run it directly instead of via inetd?

On Sun, 25 May 2008, Gelu G. Lupas wrote:

Hello. I'm having the following problem with dovecot 1.0.12 and above, on a FreeBSD 7.0 system - I'm trying to run pop3-login from inetd and I keep getting this error after authentication:

May 25 09:46:19 charlie dovecot: POP3(gelu): /libexec/ld-elf.so.1: environment corrupt; missing value for no-nuls oe-ns-eoh

The problem persists if I uncomment the lines with no-nuls oe-ns-eoh in dovecot.conf. I've also tried running pop3-login from tcpserver/ucspi-tcp and I still get the same error. Version 1.0.1 works fine on a similar setup. Please reply if you have any idea regarding a fix for this error. I need to run dovecot under a tcp wrapper of some kind (preferably inetd) as the standalone daemon doesn't allow any method to restrict access by IP. The allow_nets extra field doesn't help much as I'm using PAM and do not want to maintain yet another passdb. Restricting access via firewall rules is not an option. Until I find a way to restrict access by IP address, dovecot will only listen on the private IP address (192.168.100.1).

Dovecot does quite a bit of setup for child processes via environment variables. Maybe you could use the standalone server to run a test login, see what environment variables get set through a script, and set up an envdir (part of daemontools). Then turn off the standalone server.

e.g. (partially tested)

in /root/testing.pl (chmod +x)

#!/usr/bin/perl $dir = "/root/dovecot-env"; mkdir $dir unless -d $dir; while (my ($k, $v) = each %ENV) { open my $f, '>', "$dir/$k" or next; $v =~ tr/\n/\0/; print $f "$v\n"; } exec "/usr/libexec/dovecot/pop3-login";

and, in dovecot.conf:

protocol pop3 { #... login_executable=/root/testing.pl

Then, attempt to login.

then, via ucspi-tcp:

instead of tcpserver [options] pop3-login use tcpserver [options] envdir /root/dovecot-env pop3-login

I don't use inetd, but I'm sure a similar change could be made.

Alternatively, and far easier, would be to do something with a static db in dovecot that only has allow_nets={whatever you want}. I'm pretty sure you can have portions of user info returned via different mechanisms. (So, you'd also specify an auth db of 'PAM'.) If you don't need different allow_nets for different users, that'd be pretty simple. [I don't recall specifics on how to do this, though, so I might be off base.]

Best, Ben