On Fri, 23 Mar 2018 09:53:00 -0700
Shaun Johnson <sh...@linuxmagic.com> wrote:
> Greetings Dovecot List,
>
> I have a bit of an edge case I am trying to resolve. I am currently
> using dovecot on Ubuntu 14.04 - Ubuntu package version:
>
> 1:2.2.9-1ubuntu2.3
>
> I have attached the output of doveconf -n to this email - but to
> describe the configuration in a nutshell:
>
> my server is configured to use Maildir storage
>
> I do not use dovecot delivery service (there is a separate program
> in my system delivering messages)
>
> I am using a 'checkpassword' mechanism for authentication
>
> My mail storage is mounted via NFSv3 from a Netapp Filer FAS3050
> configured to set anonuid=89, read write access, and root access.
>
> Dovecot has been configured with:
>
> mail_fsync = always
> mail_nfs_index = yes
> mail_nfs_storage = yes
> mmap_disable = yes
> lock_method = fcntl
>
> In order to function with the other components of my system, the
> Mail Storage directories are expected to have permissions:
>
> drwx--S--- uid 89: gid 89
>
> The oddity I am encountering came up recently when I set up a job to
> monitor and correct directory permissions. I found after observing
> the system in action that overtime, the ~/Maildir directories for all
> active mailboxes would mysteriously lose the setgid bit. Now, while
> the system still functioned, it was something unexpected so I
> investigated further by turning on auditd to monitor what was changing
> the permissions on the path. After tracing through the results, I
> found an entry indicating that the 'imap' process of dovecot was
> performing a 'chown' call on the directory, with an end result of the
> previous mode 2700 being changed to 0700.
>
> Now I understand that on some filesystems, a 'chown' call can end up
> losing any setuid or setgid bits on an inode - and apparently Netapp's
> WAFL file system is one of them.
>
> Looking at the dovecot source code, I *believe* the source of the
> chown call is in src/lib/nfs-workarounds.c function
> nfs_flush_chown_uid - where a 'chown' call is being used to flush NFS
> attribute caches? for what I believe is the purposes of ascertaining
> file lock status?
>
> My question for you folks is if anyone else has encountered this on
> other file systems (or filers) - and if there is a native method in
> dovecot - either the version I am currently running or an updated
> newer version - that allows one to either retain the permissions
> assigned to a directory or specify the permissions I expect on the
> Maildir directory structures.
>
> Any feedback would be welcome, thanks!
>
>
Attached is a quick patch that I wrote up that solves the issue I
encountered. Ideally I would like to have this logic take place
dependent on if a configuration setting were set - something like
mail_nfs_preserve_permissions = yes - but I found that in order to
expose such a setting to the nfs-workarounds.c code base would require
significantly more modifications than I was comfortable with. If
anyone has any thoughts on a simple way to make this configurable, I am
open to suggestions.
Thanks!
- Shaun
diff -urN dovecot-2.2.35.ori/src/lib/nfs-workarounds.c dovecot-2.2.35/src/lib/nfs-workarounds.c
--- dovecot-2.2.35.ori/src/lib/nfs-workarounds.c 2018-03-19 02:27:54.000000000 -0700
+++ dovecot-2.2.35/src/lib/nfs-workarounds.c 2018-04-16 15:35:42.000000000 -0700
@@ -179,6 +179,14 @@
}
i_error("nfs_flush_chown_uid: chown(%s) failed: %m", path);
}
+#ifndef ATTRCACHE_FLUSH_CHOWN_UID_1
+ if (chmod(path, st.st_mode & 07777) < 0) {
+ i_error("nfs_flush_chown_uid: chmod(%s, %04o) failed: %m",
+ path,
+ st.st_mode & 07777);
+ return;
+ }
+#endif
}
#ifdef __FreeBSD__
@@ -210,6 +218,13 @@
i_error("nfs_flush_attr_cache_fd_locked: fchown(%s) failed: %m",
path);
}
+#ifndef ATTRCACHE_FLUSH_CHOWN_UID_1
+ if (fchmod(fd, st.st_mode & 07777) < 0) {
+ i_error("nfs_flush_attr_cache_fd_locked: fchown(%s, %04o) failed: %m",
+ path,
+ st.st_mode & 07777);
+ }
+#endif
return TRUE;
}
#endif
