[__opendkim[_genkey]]: potential for wrong permissions with --userid #17

Closed
opened 2022-03-09 20:05:19 +00:00 by evilham · 2 comments
Collaborator

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 --userid 2022-03-09 20:35:18 +00:00
Author
Collaborator
cc: @sparrowhawk
Collaborator

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.
fnux closed this issue 2024-05-15 11:56:17 +00:00
Sign in to join this conversation.
No milestone
No project
No assignees
2 participants
Notifications
Due date
The due date is invalid or out of range. Please use the format "yyyy-mm-dd".

No due date set.

Dependencies

No dependencies set.

Reference: ungleich-public/cdist-contrib#17
No description provided.