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

Re: Multiple Root & Hotmail -- synthesis



Hi,

On Thu, Apr 15, 1999 at 10:18:30PM -0700, mpg4@paradise.duluoz.net wrote:
> A thought-
> 
> 	It seems that two recent threads (multiple root and email
> server) both revolve around wanting to give users access without
> looking in the traditional (/etc/passwd,...) databases.  I propose a
> module (call it pam_virtual) that looks in an arbitrary database file,
> depending on the current environment.  I considered writing something
> like this to support a virtual POP server, so that's where my thought
> process is coming from, but I think we can extend it to a number of
> useful circumstances.  Here's my idea:
> 
>    - User tries to authenticate to a service.
> 
>    - His username and auth token (passwd, whatever) get passed into
> PAM, along with auxiliary information (the remote host, local host,
> current groups, time of day, whatever).
> 
>    - Based on the auxiliary info, PAM chooses which database to
> authenticate the user to, and does the authentication
> 
> 
> Take the example of a virtual POP server: a user connects to
> someipalias.foo.com.  The server gets his username and password, and
> passes them along to PAM, along with the result of getsockname().  PAM
> sees that the request came to someipalias, and authenticates the user
> to the passwd.someipalias database instead of the default.  Stir
> vigorously with a complementary NSS configuration, and voila! Virtual
> POP server.
> 
> I don't see a "nice" way to actually implement something like this,
> unfortunately.  Comments?

I've already implemented the similar construction with PNIAM
(http://www.msu.ru/pniam/pniam.html).  I use qmail-pop3d server with PNIAM
based qmail-auth program.  The application provides modules with necessary
information, modules perform authentication and authorization, and answer
application's questions about user's credentials.

Currently application passes to modules USER and PLAIN_PASSWORD items and
asks UID, GID, SUP_GROUPS and HOME.  But `conversation' between applications
and modules isn't limited.  Applications may pass and modules may check
arbitrary named items including server IP address.  Thus PNIAM provides more
flexible abstraction than NSS because
 - modules may ask a lot of information necessary for user identification;
   the information isn't limited by only a username;
 - applications may ask more information about user's identity, his resource
   limits etc; administrators may control information passing to applications
   by plugging the desired modules;
 - modules aren't obliged to provide SHELL, GECOS, and other information for
   cases where the information doesn't make a sense and isn't used by the
   application.
An additional advantage of PNIAM is an integrity of information about user.
When an application obtain some information (user id, home, resource limits
etc) PNIAM model guarantees that the information describes the same subject
(not just an information about somebody with the given username found in _a_
database).

PNIAM module which uses IP address as a user lookup key doesn't exist at the
moment.  I personally keep each virtual server with POP, SMTP, FTP, and other
services in a separate root.  However such a PNIAM module would be an
interesting and useful thing.

Best wishes
					Andrey V.
					Savochkin



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