On Mon, 12 Nov 2007, pod wrote:
"BH" == Benjamin R Haskell dovecot@benizi.com writes:
Can I just touch the dovecot.index instead?
BH> Maybe. Not sure what environment variable holds its location, BH> though. And I'm not 100% sure it always exists or whether you'd BH> have to special-case the first-time login. (Will 'touch' creating BH> a zero-length index cause trouble for dovecot? I suspect not.)
Also be aware that the script is not being run with the uid of the user - it is /usr/libexec/dovecot/imap that drops privs - so touching the index file if it does not already exist may cause problems later when the user process wants to update the index file.
Thanks for pointing that out. I'd been testing by running: dovecot --exec-mail imap which runs as the current user. (Didn't realize that.)
You could also use mail_drop_priv_before_exec in dovecot.conf (with the caveats in the comments):
# Drop all privileges before exec()ing the mail process. This is mostly # meant for debugging, otherwise you don't get core dumps. It could be a small # security risk if you use single UID for multiple users, as the users could # ptrace() each others processes then. mail_drop_priv_before_exec = yes
Or, probably better, you could put the last login information in a common directory, rather than the user's home directory (which would also make the cron job easier, I suspect).
If you have sessreg from the X11 distribution you could also try:
#!/bin/sh if test -z "$DUMP_CAPABILITY"; then /usr/bin/sessreg -a -L /var/log/lastlog -u none -w none -l imap -h "$IP" "$USER" fi exec /usr/libexec/dovecot/imap
to put an entry into /var/log/lastlog (though note you need two scripts for both IMAP and POP logins).
Since you're not doing anything protocol-specific (like echo "* OK [ALERT] Blah"), you could use the symlink trick to only require one script:
ln -s /path/script /path/imap ln -s /path/script /path/pop3
Then replace the exec with:
exec /usr/libexec/dovecot/basename $0
Also, I am bit confused. Why must the script exec imap?
It doesn't _have_ to. It's a micro-optimisation. If the script did not exec the user imap process then a /bin/sh process would be sitting around waiting for the user imap process to exit and when it did then the /bin/sh process would itself just exit.
Ah. In my other email I took the question to mean "Why must the script run imap?", but I bet this is what Matt meant.
Best, Ben