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

Re: alternate password file module?


On Sat, Jul 31, 1999 at 06:55:13PM -0500, Stephen Langasek wrote:
> On Wed, 28 Jul 1999, Jesse Off wrote:
> > Is there any PAM module available that can take a different password for a
> > user rather than the ones in /etc/passwd or /etc/shadow?  Specifically, I
> > would like to be able to have imap or pop3 servers use a separate password
> > than the one that is in the /etc/passwd database.
> I've heard talk about such a module in the past, but to my knowledge no one
> has written one yet.
> I think part of the reason for this is that it's almost never really useful.

I completely disagree with you.

I use different passwd files for virtual POP3 servers for a long time.
At the moment on one of my physical server I keep more than a dozen different
passwd files.  It's actually very useful.

> If the users are to be granted access to system resources, they have to have
> an identity recognized by the system, which means they must be present in
> the password file--or at least in some other database that can be accessed

Sorry, I don't know a single entity called `system'.
There is no such a thing in a UNIX environment.  That's more than true in the
Linux world where almost each executable has a separate author with it's own
understanding of the game rules.
Thus `system' can't recognize anything.

Where I need a username <-> uid mapping on my POP3 server?
1) For POP3 user authentication and obtaining UID, GID, mailbox location.
   That was the original question.
   I don't have a clean solution now and use a small and simple preloaded
   object file.
2) For mail delivery.  By username we should obtain UID, GID, mailbox
   location.  I use qmail's users/assign system.
3) For creating users and changing their passwords.  It's clear that existing
   programs like `useradd' can't help here.  I use my own scripts (about 100
   lines on shell and 2-3 hours of total work time).  Certainly the scripts
   adding users checks the uniqueness of usernames inside a single domain and
   preserve the global uniqueness of UIDs.  The solution is cheap and
   reliable because I know the source well and I understand all side-effects
   and hidden assumptions.
4) I also use uid -> username mapping for checking user's quota.  Another
   preloaded object file.

`Simple and reliable' - that's the slogan :-)

In the nearest future I plan to reimplement authentication, authorization,
and password changing on the base of PNIAM

> through NSS.  If you use an NSS module which reads an alternate password
> file, you have to configure this globally for the system... so every other
> application on the system will know about them as well, and you might as
> well leave them in the main shadow/password files.

On my servers I don't want any other program to know username-uid
correspondence.  Actually I'm sure that no other program knows :-)

Best regards
					Andrey V.

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