[resending mail already sent privately so that BTS is appraised]
On Mon, Aug 28, 2006 at 06:55:55PM +0200, Josip Rodin wrote:
> > > [...] But more to the point, what user are you trying to run
> > > maildrop -d with, and what is your expected behaviour? What do you
> > > expect from the -d option?
> >
> > -d ${USER} in .forward has been used because of a suggestion to do so in
> > MAILDROP_README of the postfix distribution... I guess this is not
> > correct (with recent maildrops).
>
> Yes. It appears that it was *never* correct because we never shipped
> maildrop setuid, so it was always simply being run as user.
> > The last thing I do not understand is that the maildrop that had been
> > compiled and installed manually is not suid at all, and the -d ${USER}
> > works ok. I guess this is because the ${USER} is replaced by same id as
> > the one owning the maildrop process (this is the same user). The doc of
> > maildrop seems to tell that this case of using -d is ok.
> >
> > But with the debian version (2.0.2), this doesn't work, so this seems
> > related to courier-authlib... With my own compiled version, I do not get
> > the ERR: authdaemon: s_connect() failed: No such file or directory
> > /usr/bin/maildrop: Temporary authentication failure. error at all when
> > using -d ${USER} in .forward.
>
> Yes, definitely something goes wrong with the authlib interference.
> It decides to force authlib use as soon as you use -d, regardless of whether
> you are user or root (setuid or otherwise).
>
> I'll try to debug it, and notify upstream.
--
2. That which causes joy or happiness.
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
