In litteris <[EMAIL PROTECTED]>, Josip Rodin
<[EMAIL PROTECTED]> scripsit:
> * make maildrop setgid daemon, although I don't reckon that would work
> well if you still need to setgid mail (in order to lock files in /var/mail).
That seems to work, and it's clearly better than having another setuid
binary hanging out on the disk. Thanks for the tip.
> * 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.
> * ask the maintainer or courier-authdaemon and courier-maildrop what's their
> strategy with this whole daemon user thing :)
You've got a point there. Actually, I just supposed that was the
standard Courier setup. OTOH, why should maildrop not work like
courier-maildrop does? If you think this should be optional, I'm fine
with that; and if you are busy, I could try to come up with a patch to
ask through debconf whether to setgid daemon the binary in postinst...
> * handle upgrades by dpkg-divert'ing /usr/bin/maildrop and making a note
> somewhere always to check whether you need the new one, but that's an ugly
> workaround which may fail later
I already put the package on hold, but I'm not sure I'll remind why I
did that a few months from now, and then I'll upgrade the package and
I probably will get bit by the same problem. That's my main issue.
[Of course, I could also rebuild a custom package with the setgid, but I
feel that would be overkill for such a little change]
Thanks for your insight,
-- W.
--
> Notre devoir, pour leur bien et pour le bien de Linux, est de te
> flinguer avant que tu ne les sacrifies (fût-ce avec les meilleures
> intentions du monde).
-+- TP In: Guide du linuxien pervers : "De la pédagogie par l'Exemple"
