On Tue, Oct 24, 2006 at 12:01:29AM +0200, William Steve Applegate wrote:
> > * change permissions of those files to be mail:mail
>
> That would be a lousy choice, as I suppose this change would be
> silently overridden on the next courier-authdaemon upgrade.
...no different from the permissions on maildrop binary after the next
maildrop upgrade.
You should be able to use dpkg-statoverride for both, though. Ignore my note
about dpkg-divert below, that's too much.
> OTOH, why should maildrop not work like courier-maildrop does?
Because maildrop itself isn't limited to Courier setups; it wants to lock
mail in /var/mail just as much as it wants to connect to authdaemon, if not
more, and that's how it has always been. Check the upstream documentation,
it's like that over there, too.
Also, the choice of user 'daemon' is poor - it is not necessarily restricted
to authdaemon use, so any security vulnerabilities might have a wider impact.
> I could try to come up with a patch to ask through debconf whether to
> setgid daemon the binary in postinst...
What would you suggest as the priority for such a question? For authdaemon
users, it would be high, but for all others, it would be low. Either way we
end up bothering one group, and based on the answer, breaking another :)
I could envisage dropping setgid mail on the main maildrop binary overall
in favour of lockmail, but if you look at the history, we're not actually
in sync with upstream on that matter - they setgid *only* the maildrop
binary and *not* lockmail, so that would be a further divergence.
Then again, it could also be done by removing the code in maildrop that
touches authdaemon into a separate small program and then setgid'ing that
to whatever else. The authlib connections are a work in progress (note
recent changelog), in any case.
--
2. That which causes joy or happiness.
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
