> 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/
This archive was generated by hypermail 2b30 : Fri Apr 13 2001 - 14:00:50 PDT