The debian-private mailing list leak, part 1. Volunteers have complained about Blackmail. Lynchings. Character assassination. Defamation. Cyberbullying. Volunteers who gave many years of their lives are picked out at random for cruel social experiments. The former DPL's girlfriend Molly de Blanc is given volunteers to experiment on for her crazy talks. These volunteers never consented to be used like lab rats. We don't either. debian-private can no longer be a safe space for the cabal. Let these monsters have nowhere to hide. Volunteers are not disposable. We stand with the victims.

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

Re: Need status reports on PAM and LIBC 6, please



Bruce Perens wrote:
> Obviously we can take the Red Hat patches (they don't mind) or we can
> make our own - it makes more sense for our packages to use the PAM
> _interface_ right away, so that we don't have to change everything twice.
> What I think I would like to do is use that interface but only support
> conventional /etc/passwd and shadow password support (and perhaps other
> modules that you tell us are solid) until you make your formal 1.0
> release.

If this is the case, you should probably extract the various applications
from the Red Hat distribution. They are all currently PAM aware.

"Just using /etc/passwd and shadow" simply means that you arrange the
default pam.conf file to point at pam_unix - modules. The Red Hat default
pam.conf will probably do all you need.

The nature of PAM is to make decisions about how the user is authenticated
the concern of the system administrator. You should arrange for the default
configuration to be the one you want (shadowed passwords) and then include
all the other modules for the administrator to play with as desired.

In my previous mail, I mentiontioned libpwdb. This was a bit of a red
herring -- it is not necessary to have it to make use of PAM. Some of the
modules however do use it... [libpwdb provides an alternative to the libc
calls for getpwnam etc.. It is structured radically differently to make new
fields transparently implementable. Apart from this and the ability to merge
the contents of one or more databases when looking up the identity of a
user, it performs a task equivalent to the nis enhancements to libc. libpwdb
is still under development but currently provides access to /etc/passwd
/etc/shadow nis and radius databases. I would probably not advise making
your mainstream distribution dependent on it quite yet although it is
proving to be quite stable.]


> The constraints we are under are:
> 
>     1. We must do a feature-freeze soon if we are to have an adequate
>        testing period.  Thus, we need the mimimum feature
>        set that we want to support there within two weeks at most.
> 
> 	2. We can't put in features that are so unstable that they generate
>        lots of customer service calls.
> 
> In your asessment, can we go with PAM without shooting ourselves in the
> foot?

libpam 0.55 is stable and to the best of my knowlgede is a complete
implementation of the PAM concept. I will post any fixes that are needed for
reasons of security to pam-list@redhat.com. Development (mostly in the
modules) will continue with 0.56 . Red Hat have a stable system based around
0.54 (I am told this is the library that will be in their 4.1). Because
libpam is written from a formal specification, the API is not going to
change before we get to 1.0 .

In summary, it is my feeling that you could build a reliable system around
0.55. You will have to make sure your applications abide by the API but you
can get a head start by simply adopting Red Hat's apps.

Whoever takes on the task of integrating PAM into Debian should feel free to
email me or the pam-list with questions etc. I am happy to receive patches
and suggestions; especially those that make the documentation clearer.

Best wishes

Andrew
-- 
               Linux-PAM, libpwdb, Orange-Linux and Linux-GSS
                  http://parc.power.net/morgan/index.html
       [ For those that prefer FTP  ---  ftp://ftp.lalug.org/morgan ]


--
This message was delayed because the list mail delivery agent was down.