Re: [Dovecot] How to stop mail_executable from cwd to ~home
Gary Duncan gduncan@engr.UVic.CA writes:
In our environment home directories are auto-mounted via /home/<user> including on the server provided mail. Within the various mail services though we try to isolate and override with local /mail/home/<user>
Works well except that dovecot still wants to cd to the real home triggering a useless and potentially hindering automount
This becomes really apparent if you have an organization wide-mailing list, and one delivery to it causes a flurry of automounts. I similarly replace per-user mounts with a home mount bundle.
when it invokes the imap or pop3 process specified by mail_executable, ie an lsof of the process shows cwd of /home/<user> and the automounted home.
I see the same behaviour in 2.0.13, which process tracing of imap shows more clearly (/nfs/user is per user mount, /nfs/home/user is user home bundle)
...
4087: getuid() = 12345 [12345]
4087: chdir("/nfs/test") = 0
4087: stat64("/nfs/home/test/mail", 0xFFBFF6C0) = 0
4087: stat64("/nfs/home/test/mail", 0xFFBFF5A0) = 0
4087: stat64("/nfs/home/test/mail", 0xFFBFF6C0) = 0
...This happens fairly early after imap-login forks and execs the imap process. I'll see if I can find it after building a debug version, but I think Timo will beat me to this.
Joseph Tam jtam.home@gmail.com
On Thu, 19 May 2011, I wrote:
Gary Duncan gduncan@engr.UVic.CA writes:
Works well except that dovecot still wants to cd to the real home triggering a useless and potentially hindering automount when it invokes the imap or pop3 process specified by mail_executable, ie an lsof of the process shows cwd of /home/<user> and the automounted home.
I see the same behaviour in 2.0.13, which process tracing of imap shows more clearly (/nfs/user is per user mount, /nfs/home/user is user home bundle)
This appears to be done (v2.0.13) in mail-storage-service.c in an attempt to make sure core files are dumped into a user's home directory
if ((user->flags & MAIL_STORAGE_SERVICE_FLAG_TEMP_PRIV_DROP) != 0 &&
(user->flags & MAIL_STORAGE_SERVICE_FLAG_ENABLE_CORE_DUMPS) == 0) {
/* we don't want to write core files to any users' home
directories since they could contain information about other
users' mails as well. so do no chdiring to home. */
} else if (*home != '\0' &&
(user->flags & MAIL_STORAGE_SERVICE_FLAG_NO_CHDIR) == 0) {
/* If possible chdir to home directory, so that core file
could be written in case we crash. */
if (chdir(home) < 0) {
... debug diagnostics ...
}
}As to how to stop the mail process from chdir'ing to a home directory rather than putting core files somewhere else, I don't know how to do it without altering the source code or wrapping these processes in something that alters the HOME environment variable.
I also can't find how user->flags sets MAIL_STORAGE_SERVICE_FLAG_NO_CHDIR or MAIL_STORAGE_SERVICE_FLAG_ENABLE_CORE_DUMPS that could influence this behaviour.
Joseph Tam jtam.home@gmail.com
On 21.5.2011, at 10.51, Joseph Tam wrote:
On Thu, 19 May 2011, I wrote:
Gary Duncan gduncan@engr.UVic.CA writes:
Works well except that dovecot still wants to cd to the real home triggering a useless and potentially hindering automount when it invokes the imap or pop3 process specified by mail_executable, ie an lsof of the process shows cwd of /home/<user> and the automounted home. I see the same behaviour in 2.0.13, which process tracing of imap shows more clearly (/nfs/user is per user mount, /nfs/home/user is user home bundle)
This appears to be done (v2.0.13) in mail-storage-service.c in an attempt to make sure core files are dumped into a user's home directory
That's one reason, yes. It's also needed when doing chrooting. And in general it's cleaner..
As to how to stop the mail process from chdir'ing to a home directory
If you don't want Dovecot to use a home directory, don't tell it a home directory.
participants (2)
-
Joseph Tam
-
Timo Sirainen