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

Re: thinking about pam



Andrew G. Morgan:
>  It is new. So you are likely to be unhappy... :(

Unless you can convince Sun to use it too... :)  (not that I think this
would be the case here)

> It is likely to provide some overlap with the nss stuff, but it offers one
> feature that is not (to my knowledge) offered by nss, namely the application
> is at liberty to request data from the default or a specified database.

You can do that with NSS - the modules have a documented interface, you
can use that directly.  Unfortunately, the interface is not compatible
with the Sun's one - the main reason being that the latter seems to be
undocumented.  [Is anyone from Sun listening?  Would it be possible to
make the documentation about the Sun's NSS modules interface available?
Do these modules also provide some way to change the information in the
specified ("passwd -r xxx") source?  If yes, I think we should do it
the same way.]

> Having obtained data from the default database, it is clearly labeled with
> its source; which database it came from. This will make it easier to
> distribute accounts among a number of different databases, and for

Perhaps the NSS functionality in glibc could be extended to make this
possible?  One possible solution would be to add a "where did this info
come from" field to struct passwd, struct spwd and so on.  While it is
non-standard, existing sources won't break - they won't even notice the
extra field.  Existing binaries will - too bad that some of the Linux
ports are already using glibc as the standard libc :-(.  (But maybe it
is better to change struct passwd sooner than later - it would be nice
to change a few other things while we are at it, for example use 32-bit
instead of 16-bit UIDs.)

Another possibility is to add a new function to return the name of the
source used for the last getpwnam() etc. call - something like this was
done in the shadow suite (but only if you use its own getpwnam() which
is disabled by default) - __ispwNIS() returns 1 if the last entry came
from a NIS server, or 0 - from the local /etc/passwd file (NIS+ probably
didn't exist at the time the code was written).  This doesn't break
existing binaries, but the interface is not reentrant, so we would need
a reentrant version as well.

Either way, I think the work that has been done in glibc should not be
ignored - and no, the code is not derived from the shadow suite, so don't
be afraid of its quality :).  It was written from the specs by the glibc
maintainer, Ulrich Drepper <drepper@cygnus.com>.

I can see the problem with contributing the code for glibc - you need
to do the paperwork with the FSF (I wish they could get with the times
and at least accept PGP-signed copyright disclaimers via e-mail...),
but we can always send some suggestions to the glibc maintainer, who
would implement them.

Besides, I don't think we want to change *all* applications to use the
new and great libpwdb API instead of the old but standard (specified by
POSIX) getpw*().  Let's not make life even harder for those poor guys
who write portable software...

I agree that we need some way to update user information.  But I think
we should first try to find out how it was done on other systems, before
deciding that we should do it our (possibly better but incompatible with
the rest of the world) way.  And let's leave applications not related to
authentication alone (using the standard libc functions) - there are just
too many.  Remember that only 20 or so apps which need to authenticate
the user and need to be changed to support shadow passwords were enough
to start a discussion how bad idea this is (see the linux-security list
archive), how to do it better, and started the PAM project - and now it
seems that we start changing everything else just to get PAM working :(.

> I will send you the working documentation tomorrow - let me tidy it up first

Thanks, got it.  One question (not directly PAM-related) - I have seen
a reference to RADIUS.  Do you have any free RADIUS client code?  I ask
because some time ago I added RADIUS support to the shadow login, but
not many people use it, because you need to get some code separately.
The problem is that the code (from ftp.spsystems.co.za - oops, it isn't
there anymore) has no clear copyright statement (just says that it's
copyrighted, and doesn't tell me that I can freely use and distribute
it; ISP's might not care, but distributions do, at least Debian does).

Regards,

Marek



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