Re: More problems with QPOPPER - <sigh>

[dustin () spy net (Dustin Sallings)]

> The answer to all this is of course cucipop, by S. R. van den Berg (of
> procmail fame):
>
>         ftp://ftp.informatik.rwth-aachen.de/pub/packages/cucipop/

        Looks to me like that still runs as root:

static const auth_identity*transmogrify(const auth_identity*pass)
{ initappdb();opendb();
  return setuid(auth_whatuid(pass))?(auth_identity*)0:pass;
}

        That function is called by a function 189 scary lines into main.  They
make very good use of space, too, so it'd take a while to figure out how much
stuff happened before that:

main(int argc,const char*const argv[])
{ unsigned loginattempts=0,quiet=0,debug=0;short port=POP3_PORT;
  unsigned douser=1,douidl=1,doapop=1,dotop=1,autodel=0,sabotage=0;
  static const char tdotnl[]=".\r\n";time_t agecutoff=-AGETOLERANCE;
  openlog(cucipopn,LOG_PID,LOG_FACILITY);sockin=stdin;sockout=stdout;

        It may be secure to safely run as root, but it would take a pass
through indent and quite a bit of code review (and expansion) before I'd feel
safe running it.

        Try cyrus, which in my installation at home never touches any UID other
than 5003:

        http://andrew2.andrew.cmu.edu/cyrus/

        It's an IMAP server that does POP, too.  While there may be buffer
overruns, etc... in these daemons, I feel a little better knowing that there's
one less service running as root, and one less service that will not
immediately dump out a root shell if someone overflows a stack.  Not to mention
my mail server only has UNIX accounts for administrative users, so it's that
much harder to break.

        Generally, if I find myself doing something as root, I start searching
for a way to tie it down to a less painful uid.  It's no excuse for bad code,
but it's a pretty big layer of padding.

--
dustin sallings
http://2774144194/~dustin/