SQLite driver and auth-worker credentials

[james at lottspot.com]

>   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 at 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-----