Re: Virtual User/Alternative Authorization Methods

[Alain Magloire]

Bonjour

> Hello Alain, hope the squirrel battle is going well.

The warfare is still on, 'she' loves almonds and peanut butter, but
does not pay attention to the chocolates.

> Looked over both the IMAP and IPOP server sources to see what needs to be
> done to support various authentication methods.  Here's the goals that I
> think are important:
> 

Note: imap4d/* is very young, work in progress.

> 1.  Support normal passwd/shadow & PAM authentication methods

pop4d/* has support for PAM, APOP, and SHADOW(done by Jakob).  since I dislike
#ifdef's, I'm certainly open to new ways.

> 2.  Support alternative-location crypt'd/SHA passwd files for virtual
> domains
> 3.  (Eventually) support LDAP/MySQL since this is gaining in popularity for
> virtual user systems

This sound really cool, but is there a way to do this by isolating the specifics
in functions.  If you ever looked at wu-ftpd, you know what I mean, it's a
nightmare, a maze of ifdefs (Kerberos5, kerberos4, Opie, Pam, shadow,
acl's, ...).  Doing this modular, will permit better integration to daemons
(pop4d, imap4d, etc ..) and easy code maintenance.

> 4.  Provide measures for the daemon to run as a neutered user on the system
> for virtual logins

You'll have to give more.  So far for the pop4d or imap4d if not run
via inetd, it's run as root then a setuid() is done when authenticate.

> With repsect to imap4d, the obvious place to build this is in login.c.  It
> appears that the username/password is checked here regardless if cleartext
> or cyphered passwords are used.

Yes, the imap4d code is unfinish, so far only one type of AUTH is supported
LOGIN.

> The issue to overcome is that the rest of
> the sources use the struct passwd/struct shadow for the mailbox & user
> information.

You mean this in select.c :
 if (strcasecmp (mailbox_name, "INBOX") == 0)
    {
      pw = getpwuid (getuid ());
      if (pw)
        mailbox_name = pw->pw_name;
    }

> I don't know how difficult it would be to use your own
> structure set upon authentication that contains path to the mailbox, mailbox
> name, user:group to setuid, etc.

Is this for Virtual support? Ok instead of fetching the the mailbox_name
via getpwuid() we can explicitly set in a global struct/variable.
But user:group --> setuid(), it is not clear to me why is the necessity,
as soon as the AUTH state is done, you setuid(), no? this is also done for 
security concerns.

The idea of the virtual looks fun and feasible, can we agree on set
of API functions that the daemons could use?

-- 
au revoir, alain
----
Aussi haut que l'on soit assis, on est toujours assis que sur son cul !!!