dovecot CAN NOT open SQLite database with read-only permissions set! It is problem №1 in my message: it uses sqlite3_open() API which requires read-write access and fails otherwise.

What I'm talking about has nothing to do with the sqlite3 API. The API is not how you *securely* enforce read-only access to a sqlite3 database. If you need to enforce read-only access, you will need to do so using filesystem permissions modes (i.e., use chmod and chown to set the read bit for the user or group which will read the database, and unset the write bit for the same user or group).

But system should assign all secondary GIDs to effective UID?

Not the case. Changing the effective uid of a process does not associate the process with any of the groups which the user it has inherited are associated with. The process must explicitly call setgid in order to change its effective GID. This is also why dovecot services have a separate 'group =' directive in addition to the 'user =' directive (http://wiki2.dovecot.org/Services).

In order to achieve the configuration you desire, you need to set the group of the auth-worker service to hostingdb and set filesystem permissions on the database to 640. Forget about trying to alter the behavior of sqlite3_open.

On 2016-02-24 14:18, Lev Serebryakov wrote:

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA512

On 24.02.2016 21:49, james@lottspot.com wrote:

...

The only secure way to enforce read-only access on a sqlite database is via filesystem permissions. I would recommend setting your database to 640 and ensure that any modifying process runs with the owning UID. dovecot CAN NOT open SQLite database with read-only permissions set! It is problem №1 in my message: it uses sqlite3_open() API which requires read-write access and fails otherwise.

...

Dovecot processes will not assume they should run as a GID based on the UID to which they are assigned; you need to explicitly set the GID of But system should assign all secondary GIDs to effective UID?

...

the process (pretty sure this is the case anyways). Neither I or anyone else on this list though will be able to offer much more guidance than that unless you supply your doveconf -n output.

Relevant parts:

======================= passdb { args = /usr/local/etc/dovecot/dovecot-sql.conf.ext driver = sql }

userdb { args = /usr/local/etc/dovecot/dovecot-sql.conf.ext driver = sql }

service auth-worker { user = $default_internal_user }

And I have:

% grep dovecot /etc/group dovecot:*:143: hostingdb:*:999:postfix,dovecot % ls -l /usr/local/etc/hostenv/db/mailhost.sqlite

• -rw-rw---- 1 root hostingdb 14336 24 Feb 14:47 /usr/local/etc/hostenv/db/mailhost.sqlite % sudo su -m dovecot -c id uid=143(dovecot) gid=143(dovecot) groups=143(dovecot),999(hostingdb) %

---

// Black Lion AKA Lev Serebryakov -----BEGIN PGP SIGNATURE----- Version: GnuPG v2

iQJ8BAEBCgBmBQJWzgIBXxSAAAAAAC4AKGlzc3Vlci1mcHJAbm90YXRpb25zLm9w ZW5wZ3AuZmlmdGhob3JzZW1hbi5uZXRGOTZEMUNBMEI1RjQzMThCNjc0QjMzMEFF QUIwM0M1OEJGREM0NzhGAAoJEOqwPFi/3EePIK0QAJk0nTOGCCxc/A5LqLKbYzX4 9fKQKrfLfWZfKcdRW0flLefcrCj2AAL9aM/KybKDOIR/IqC/+s8KwLLi/VN0+CSa UaKOca2LsMJtiOVy0DOs+KXS5ynpBeTZ9UCna2lVlySoVNsXPw2pQ+uSQYtKFrVQ SRmF6XanVndW4mH7x0Pj4YJwSE55FC+RcuNP94th4uIHavV7LCjFuv4O7hTSax7d RuBxkW52ILZaD4RICHQ6T5bmhCUVgzmYNw2NV/sZdvT5CH6rszPQU8VR/3I3FYp5 /8rNXaScOgQ351WEBI/K9s8IjvazZjKi6jE0auvJb0qw0tD0N3UCrfALtIOKLcbb GWacmqlogidVYMgaggPJBEu4W6bkqBxDICp2FXvIzzRGuwYv4dks+IxLDpHIfZyH PrQLDK4qBsBo3/4dTd3CxJddHMYM1Hdnswntg/S2hwt6g20ZE+WB1YhPUWyfiFMh 0sn4timpuxW40AzYIO6jtE7/HB0hUMCajKiBemcVb8P4bMXmTSeLaflhYlq1/zty lDYcT+qIb29ug7rBY0ljuOWRSYTq8JJTxuM3QEJbjDLKmucNsGRmcF1j1Yb9fnZl 6jicP0CSyWvGtD051mz1AIBoT6WW1xtB6g/0gBnyEIHD2TSEWad53lZM8Kq3h6OD d8eBgznhx4DwJjF4u7XZ =OOJa -----END PGP SIGNATURE-----