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, ja...@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-----
