bug-mailutils
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: SUID pop3 / imap4?


From: xystrus
Subject: Re: SUID pop3 / imap4?
Date: Thu, 4 Apr 2002 20:03:46 -0500
User-agent: Mutt/1.3.27i

On Wed, Apr 03, 2002 at 06:37:55AM -0800, Jeff Bailey wrote:
> I got a bug report from someone who has been doing pop3 over ssh with
> qpopper before we switched to mailutils.  I can reproduce it easily
> enough:
> 
> address@hidden:~$ /usr/sbin/pop3d 
> Error setting mail group: Operation not permitted
> address@hidden:~$ ls -al /usr/sbin/pop3d
> -rwxr-xr-x    1 root     root        33832 Feb 21 21:07 /usr/sbin/pop3d
> 
> I'm not sure what the Right Thing is here.  I can set the pop3d to be
> SUID root, which allows it to work.  I tried making it SUID mail, and
> it loads, but it can't get past pam.

You donn't need to make it SUID, you need to make it SGID.  In this case,
it's already running as the user it needs to be, so it doesn't need to
perform a setuid() call.  It only (potentially) needs to be able to create
the user's spool file, so it needs write access to the spool directory,
which only requires that it have the group permissions of the mail group.

> I just hate SUID binaries... =)

Another alternative exists.  You could make a more modular design, breaking
up the POP3 daemon into two parts: one part to handle incoming connections
from the network, and handle authentication, and a second part to handle
everything else.  IIRC qmail does this sort of thing, in order to
drastically reduce the amount of code it needs to run as root.  Sendmail
does it now too, though perhaps not as effectively as (I hear) qmail does it.

The first part runs with root permissions so that it can bind to port 110
and so that it can call setuid() as needed.  Then, once it's running as the
user it needs to be, it execs the second part, the actual POP3 daemon.  A
user who wanted to access their spool via POP3 over SSH could do so by
running the second part.  You could call them pop3cond and pop3d or
something like that.

pop3cond would still need to run with root priviledges, but needs only to
handle connections from the outside world.  Local users need not run it at
all.  The amount of code that needs to be carefully scrutinized is much,
much smaller, in that case.  

The best part is, the second daemon need not run with ANY priviledges other
than running as the user, if the spool directory has the permissions
01777 (sticky bit set) and the spool files themselves all have the
permissions 00600.  In a more standard configuration though, it will need to
be SGID mail, as typically the spool is set like:

  drwxrwsr-t    2 root     mail         4096 Apr  4 19:42 /var/mail
or
  drwxrwxr-x    2 root     mail         1024 Feb  6  1996 /var/spool/mail/

Xy




reply via email to

[Prev in Thread] Current Thread [Next in Thread]