dovecot - Apr 2018 - File system permissions - setgid bit and Netapp NFS volumes

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!


-- 
Shaun Johnson
LinuxMagic Inc.
604-682-0300 Beautiful British Columbia, Canada

-------------- next part --------------
A non-text attachment was scrubbed...
Name: doveconf_output
Type: application/octet-stream
Size: 1546 bytes
Desc: not available
URL:
<https://dovecot.org/pipermail/dovecot/attachments/20180323/d5c639bc/attachment.obj>

On Fri, 23 Mar 2018 09:53:00 -0700
Shaun Johnson <shaun at 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
-------------- next part --------------
A non-text attachment was scrubbed...
Name: preserve_permissions.patch
Type: text/x-patch
Size: 980 bytes
Desc: not available
URL:
<https://dovecot.org/pipermail/dovecot/attachments/20180416/c8186f30/attachment.bin>

On 17.04.2018 01:42, Shaun Johnson wrote:
> On Fri, 23 Mar 2018 09:53:00 -0700
> Shaun Johnson <shaun at 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