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

Re: GDBM/DB password file support

On Wed, 9 Oct 1996, Andrew G. Morgan wrote:

> Elliot Lee wrote:
> > 
> > Has anyone done/is-doing this? If not, I may give it a try.
> GDBM/DB ? What is that?

Sorry for the confusion. I meant gdbm or berkeley db. It's the same idea
that sendmail uses for its aliases database.

> If you are asking about libpwdb here, take a look at
> 	http://parc.power.net/morgan/libpwdb/index.html
> The documentation is very much in flux.. But it helps to have something
> written down. I will make .ps available once I have a working application
> and module..

A few comments:

- The config file format probably should be a bit more flexible.

		| CONFIGFILE dblist
	dblist: 'databasename' ':' whitespace sourcelist
	sourcelist: 'sourcename'
		| sourcelist whitespace 'sourcename'
	whitespace: '[ \t\n\r]+'
That way people could do syntax like /etc/nsswitch.conf if they wanted, or
put one thing per line if they wanted. Also it says
"The nameN items being one of the following: nis, unix, radius and shadow."
That should probably just be changed to "The nameN items being the data
source for the database in question. Examples are nis, unix, radius, and

- A DNS module will be needed eventually, for host map lookups...? (Or are
we only doing user-database things here?) Also a hesiod module (hesiod
basically uses DNS to store the passwd & group maps). It might make sense
not to restrict this API to just user & group lookups.

- The memory allocation on the user's side of things looks kind of messy.
Any way to hide that? The sample code didn't seem to need it, though, so
that may not be an issue (yet).

- Things from different sources are seeming to be a bit complicated. I.e.
the stipulations that you can't ask for this info from this module, and
you can't use a UID to get info from raduis, for example. Why not just
have a password structure that holds all the elements of information one
could possibly have on a user or group (or an associative array type of
thing). The application could fill in whatever information it has on the
user (i.e. if it has a UID, pass UID in, if it has username and GECOS pass
that in). Then libpwdb would go through the modules one by one getting
them to fill in whatever information they have on the user, and out comes
a nicely populated user/group information structure. This would have
problems if two different user databases had conflicting entries for a
user, but this is likely to happen only for authentication tokens, which
PAM modules will take care of anyways.

libpwdb modules could also each return a value that says whether they
found the user in their database or not. If none of the modules find a
user, then libpwdb returns back to the program with PWDB_NOT_FOUND

<My too-long $0.02 ends> Comments/flames welcome.

Hope this helps,
-- Elliot

"Have you ever had a microchip implanted in your skull so the government
can keep track of your every move? You will! And the company that will
bring it to you is AT&T"

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