RE: Virtual User/Alternative Authorization Methods

[Jeff Breitner]

> > 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.

You're going to have her packing on so much weight she won't be able to get
out of the house.


> 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.


It's going to have to be modularized.  I've made the mistake on more than
one occasion of using ifdefs and compile-time directives to plug in certain
functions.  I liken this to a night out at the bar, it's all fun while it's
going on and it works out ok in the short-term, but you sure hate yourself
in the morning.


>
> > 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.
>

Once the virtual user is authenticated, it setuid's to something other than
root.  In my current situation, I setuid to "virtuser", which owns all the
mail folders and inboxes for non-system users.



> > 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.


Exactly.  Login.c sees that the username is address@hidden, assumes this is
intended as a virtual user and calls the virtual user login routine.  If
successful, it sets the user information in the global struct, if not the
login fails.  If this user appears to have a system account, it validates it
via getspwnam() and fills out the global struct.

My thoughts are that you'd setuid upon successful validation of the user.


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

Let me ponder some function ideas today.  I guess the first function would
support the two widely used password file schemes I've seen for virtual
users.  The first is just a long file that has address@hidden:crypt'd
password and the other is a clone of /etc/passwd (except it has the actual
crypt'd password) placed in a directory and or file unique to the virtual
domain.