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

Re: GDBM/DB password file support

On Thu, 10 Oct 1996, Elliot Lee wrote:

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

libpwdb was intented to help us with user / group lookups. But I agree 
that a hesiod module should be nice. I don't have the docs/idea how to do 
it, though.

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

No, it is not an issue. Using the generic code things are simple as that. 
But how it's done this internally in libpwdb... 

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

You are very right. libpwdb is doing _exactly_ what you have described. 
The docs you were referring to (paragraphs) say in clear that you can not 
rely on radius module only to handle user login (actually, this can be 
done, but with a suitable radius PAM session module...). But when more 
databases are used at once, a nice struct is filled up with data from 
different modules, etc.

Consider for example that is possible for RADIUS users to not have 
corresponding entries in a standard passwd database. In this case it is 
the responsability of the application to handle this cases, pwdb is meant 
as an interface. We can not set things in some way in pwdb and later 
regret that. For most things, the application making use of the generic 
interface knows better what is needed...

So for short, you (still) don't need to worry :-). pwdb is working 
exactly as you written you'd like to...

> 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

Done already :-)

		Cristian Gafton
Cristian Gafton                                    gafton@sorosis.ro
Computers & Communications Center              Network Administrator
35 Moara de Foc St., Iasi 6600, ROMANIA           Tel: +40-32-252938
http://www.cccis.ro                               Fax: +40-32-252933
UNIX is user friendly. It's just selective about who its friends are.

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