Porting these types to work on FreeBSD I noticed that __opendkim has support for a --userid parameter.
OTOH, __opendkim_genkey just uses chown opendkim:opendkim KEY.private; therefore assuming that the service runs with those credentials.
Without knowing the internals of Alpine, I can imagine this being an issue as per opendkim(8):
Thus, keys referenced by the KeyTable must always be accessible for
read by the unprivileged user. Also, run-time reloads are not possible
if any of the other files will not be readable by the unprivileged
user.
Instead of making things complex, I suggest deprecating __opendkim's --userid argument; does that sound ok? Which use-case am I missing?
Porting these types to work on FreeBSD I noticed that `__opendkim` has support for a `--userid` parameter.
OTOH, `__opendkim_genkey` just uses `chown opendkim:opendkim KEY.private`; therefore assuming that the service runs with those credentials.
Without knowing the internals of Alpine, I can imagine this being an issue as per `opendkim(8)`:
Thus, keys referenced by the KeyTable must always be accessible for
read by the unprivileged user. Also, run-time reloads are not possible
if any of the other files will not be readable by the unprivileged
user.
Instead of making things complex, I suggest deprecating `__opendkim`'s `--userid` argument; does that sound ok? Which use-case am I missing?
evilham
changed title from __opendkim[_genkey]: potential for wrong permissions with --userid to [__opendkim[_genkey]]: potential for wrong permissions with --userid4 months ago
Uuugh, pretty sure that's a loosely concentrated me trying to ease further generalization of the type without actually thinking it through. We don't use that parameter anywhere, and I don't see why anyone would want to use another user than the one that is preconfigured in the package for their distribution.
Go for deprecation.
Uuugh, pretty sure that's a loosely concentrated me trying to ease further generalization of the type without actually thinking it through. We don't use that parameter anywhere, and I don't see why anyone would want to use another user than the one that is preconfigured in the package for their distribution.
Go for deprecation.
Porting these types to work on FreeBSD I noticed that
__opendkim
has support for a--userid
parameter.OTOH,
__opendkim_genkey
just useschown opendkim:opendkim KEY.private
; therefore assuming that the service runs with those credentials.Without knowing the internals of Alpine, I can imagine this being an issue as per
opendkim(8)
:Instead of making things complex, I suggest deprecating
__opendkim
's--userid
argument; does that sound ok? Which use-case am I missing?__opendkim[_genkey]: potential for wrong permissions with --useridto [__opendkim[_genkey]]: potential for wrong permissions with --userid 4 months agocc: @sparrowhawk
Uuugh, pretty sure that's a loosely concentrated me trying to ease further generalization of the type without actually thinking it through. We don't use that parameter anywhere, and I don't see why anyone would want to use another user than the one that is preconfigured in the package for their distribution.
Go for deprecation.