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

Open
opened 4 months ago by evilham · 2 comments
evilham commented 4 months ago
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 4 months ago
Poster
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.
evilham referenced this issue from a commit 3 months ago
Sign in to join this conversation.
No Milestone
No project
No Assignees
2 Participants
Notifications
Due Date

No due date set.

Dependencies

This issue currently doesn't have any dependencies.

Loading…
There is no content yet.