On 17.04.2018 01:42, Shaun Johnson wrote:

On Fri, 23 Mar 2018 09:53:00 -0700 Shaun Johnson <shaun@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