21.12.2024 18:31, Wietse Venema via Postfix-users wrote:
Michael Tokarev via Postfix-users:
It *feels* like postfix needs some separation of this sasl stuff into
its own process somehow, similar to how proxymap is done, so that
eg cyrus sasl code is not linked directly into smtp[d] with all its
large code. If we don't use sasl-based session encryption, it should
be relatively easy. This daemon can have its own privileges which
allows it to work with secrets database without granting access to
it to whole postfix.
What parts of the libsasl API require root privileges? This is
rather new ot me, 25 years into Postfix SASL support. I thought
that saslauthd provides the privilege separation that is needed
for shared-secret access.
None require root privs besides saslauthd itself accessing system
user/password database.
I'm not talking about requiring root. I'm talking about any SASL
mech besides PLAIN (& LOGIN) which can not be done with saslauthd
and require direct access to password storage by postfix.
Dovecot AUTH calls are already RPCs and does not need a proxy.
Indeed.
Maybe there should be a proxy code between dovecot auth protocol
and cyrus sasl code, - one side implements dovecot auth for other
parts of postfix to use, and the other side to use whatever non-
PLAIN mechanisms provided by cyrus sasl.
For regular postfix processes, implement dovecot sasl only, which
should reduce complexity further. Maybe also implement saslauthd
_protocol_ (the very simple write(user,password), read OK|BAD back,
that should be about 20 lines of code or so), without the actual
cyrus sasl libraries involved.
Take a look at SASL_README. saslauthd only supports PLAIN/LOGIN,
anything else in cyrus sasl requires direct access to secrets
storage.
/mjt
_______________________________________________
Postfix-users mailing list -- postfix-users@postfix.org
To unsubscribe send an email to postfix-users-le...@postfix.org
