dovecot - Feb 2016 - SQLite driver and auth-worker credentials

I want to use SQLite database as storage for auth and user databases.
I've encountered two problems here:

 (1) There is no way to open SQLite database read-only (via
sqlite3_open_v2() call with SQLITE_OPEN_READONLY flag). It looks bad. I
don't need (and want) to give dovecot rights to write to this database.

 (2) I've created system group "hostingdb", added
"dovecot" user to it
and gives 660 rights to database file, but still "auth-worker" could
not
open database and complains to log file. Now I'm set "user = root"
for
auth-worker, but I don't like it! Why auth-worker doesn't belong to
"hostingdb" group?


-- 
// Black Lion AKA Lev Serebryakov

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 949 bytes
Desc: OpenPGP digital signature
URL:
<http://dovecot.org/pipermail/dovecot/attachments/20160224/da36fe66/attachment.sig>

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

On 2016-02-24 13:31, Lev Serebryakov wrote:
> I want to use SQLite database as storage for auth and user databases.
> I've encountered two problems here:
> 
>  (1) There is no way to open SQLite database read-only (via
> sqlite3_open_v2() call with SQLITE_OPEN_READONLY flag). It looks bad. I
> don't need (and want) to give dovecot rights to write to this database.
> 
>  (2) I've created system group "hostingdb", added
"dovecot" user to it
> and gives 660 rights to database file, but still "auth-worker"
could
> not
> open database and complains to log file. Now I'm set "user =
root" for
> auth-worker, but I don't like it! Why auth-worker doesn't belong to
> "hostingdb" group?

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