Thank you for the feedback. Indeed, the long term proposal would
require calling fork, so making privsep completely transparent to
users of libtls does not seem feasible. However, the patch in this
thread does not go this far.

This patch aims to make it easier to write privsep. Instead of using
tls_config_use_fake_private_key of libtls and updating RSA_METHOD
or EC_KEY_METHOD of libcrypto, users can now specify the signing
callback directly via tls_config_set_sign_cb. It seems such usage
was intended by the creators of tls_signer. The integration into
relayd is only an example, but it already shows it is less work to
setup privsep.

Of course, we would need to improve the relayd patch and create one
for smtpd, but we think the libtls part is already an improvement.
Would you be interested if we complete this work?


On Sat, Apr 13, 2024 at 6:41 PM Mark Kettenis <mark.kettenis@xs4all.nl> wrote:
>
> > From: "Theo de Raadt" <deraadt@openbsd.org>
> > Date: Sat, 13 Apr 2024 10:32:56 -0600
> >
> > If I understand this proposal, it is that libtls would eventually
> > start to call call fork.
> >
> > I think it is not a good idea to have libraries that call fork
> > themselves.  It is something that a program should be responsible
> > for, not a library.  Programs handle process hierarchies and the
> > consequences of having children, and this should not be a surprising
> > feature of using a library.
>
> 100% agree.  A long time ago I did some work on implementing grantpt()
> in glibc using a setuid helper program.  Let's say I was young and
> naive...  But it didn't end well.
>