On 17.04.2018 01:42, Shaun Johnson wrote: > 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
Hi! Thank you for your patch, we would appreciate if you'd be able to open it on https://github.com/dovecot/core against dovecot master branch. Aki
