Created attachment 1007828 [details]
Patch suggestion which adds a more restrictive umask

I discovered an issue in zarafa-search (being part of Zarafa >= 7.2.0),
which is that the daemon creates the directory /var/lib/zarafa/search/
with the permissions root:root and 777 (read- and writable for world),
if the directory does not already exist. Subsequently all files inside
of /var/lib/zarafa/search/ created by the zarafa-search daemon are also
read- and writable for world (independent of the permissions of parent
directory).

/var/lib/zarafa/search/ is the default directory according to index_path
setting in /etc/zarafa/search.cfg. Depending on the packaging this issue
might be mitigated (e.g. parent directory with zarafa:zarafa and 750).
However the index_path value can be changed by an administrator and just
relying on a packaging that might mitigate the issue isn't IMHO correct.

Inside of /var/lib/zarafa/search/ the index (created via xapian) of the
Zarafa content is stored, thus the index files contain words and phrases
from e-mails, contacts, calendar entries etc.

/usr/lib*/python2.?/site-packages/zarafa/daemon/daemon.py is where the
wrong permission comes from. But the same file also states the behaviour;
the mentioned file itself is copied by Zarafa from python-daemon:

        `umask`
            :Default: ``0``

            File access creation mask (“umask”) to set for the process on
            daemon start.

            Since a process inherits its umask from its parent process,
            starting the daemon will reset the umask to this value so that
            files are created by the daemon with access modes as it expects.

While above might leave some space if the origin is within Zarafa or the
python-daemon the following is IMHO much more clear. Note that the (above)
bundled python-daemon is 1.6 while the following is from 2.0.5:

        `umask`
            :Default: ``0``

            File access creation mask (“umask”) to set for the process on
            daemon start.

            A daemon should not rely on the parent process's umask value,
            which is beyond its control and may prevent creating a file with
            the required access mode. So when the daemon context opens, the
            umask is set to an explicit known value.

            If the conventional value of 0 is too open, consider setting a
            value such as 0o022, 0o027, 0o077, or another specific value.
            Otherwise, ensure the daemon creates every file with an
            explicit access mode for the purpose.

So the issue is IMHO that the zarafa-search daemon does not set the correct 
umask before calling python-daemon's DaemonContext().