On Mon, 12 Nov 2007, pod wrote:
"BH" == Benjamin R Haskell <[EMAIL PROTECTED]> 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