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

Re: PAM, When?



Jim,

[BTW, you might like to revisit the "securelevel" thing.  So far as I
can tell, Linux is not really pushing in that direction any more. 
Instead, fine grain privileges/capabilities are in more recent kernels
(2.1.92+ I think).]

I feel like you want me to say something.  I'm not sure what you want to
hear.

On the version number thing, I'm basically not bothered.   If you
prefer, you can think about 0.6x as being version 6.x.  From my
perspective, it sort of feels like PAM does ~65% of what I think needs
to be done.

PAM as described in the original RFC is completely implemented.  If what
was in there was "good enough", I'd have bumped up the release number to
1.0 and would
probably have called it a day. My big picture view is that PAM, as
defined in the original RFC, is devoted to the login-on-a-tty problem,
something that is getting less and less close to what people actually
do.  I'd like to shift the emphasis from the tty to the client-server
interface, with a view to accommodating X-programs and machine-machine
authentication.  If that could work I think we'd be in the area of 90%.

The sad reality is that PAM is not addressing everyone's authentication
needs.
Witness the activity around GSSAPI, SASL etc.. (See Ted's note and the
corresponding RFC's.)  Andrey is also proposing another pluggable
scheme.  Someone will end up getting it right enough for people to use.

My personal opinion is that with more work, mostly on applications
(_clients_ and servers), PAM could be everything to all.. But, I may
well be wrong.  I may also be too slow/late (my life is more complicated
now I have a "real" job, am expecting a first child etc.).

So, PAM is at the point where it will either stagnate, not progressing
beyond solving the problems it currently solves etc., or I or someone
else will come up with some code that expands its usefulness once
again.  It was relatively trivial to implement the original RFC, which
is a pretty well thought out document.  What is proving harder is to
expand on this base in a way that is backwardly compatible and at the
same time flexible enough for future needs.

My personal efforts are going into implementing two things: binary
prompts and the accompanying client-side authentication agents; and the
whole issue of accommodating event driven programming.  I'm currently
working (if you can count the hour or two a week that I seem to be able
to find for it) on the latter.  I've placed a stake in the ground with
the beginnings of another RFC.  The only email I've got back about that
was pretty non-technical so I've made little change to it.

Perhaps I should really turn the question around.  Perhaps people on the
list have strong opinions/code they want to contribute?  What should be
in 1.0?

  1. specifically, what do you feel is weak about PAM?

  2. would you object if I broke Linux-PAM up into separate packages:
libraries; documentation; modules? (*)

  3. do you think binary prompts (in a nutshell, adding arbitrary
flavors of conversation types to PAM) and accommodating event driven
programming, are the highest priorities for developing PAM?

(*) I would like to do this.  In the past, people have objected because
it makes the job of assembling the pieces harder.  Unfortunately, for
the same reasons, it places a burden on me that I am less and less able
to bear.

Looking forward to some discussion.. :^)

Andrew

Jim Dennis wrote:
> 
>  Last year I agreed to do an article for sysadmin magazine's annual
>  Linux issue (January).  It was to give overviews of PAM and
>  the "securelevel" kernel features (among other things).
> 
>  Back in September or August of '97 I figured that PAM 1.0 and the 2.2
>  kernels were only a few months away and that my article would be
>  timely. (O.K. --- I was *way* wrong).
> 
>  So, now I pose this question:
> 
>         How close are we?
> 
>  ... what needs to be done before we can call PAM a 1.x release?
> 
>  Should I even *consider* proposing an article to them for their
>  next January issue?  (Mind you, I have no idea where Amber will
>  speak to me after the last flub --- but that's my problem).
> 
> --
> Jim Dennis  (800) 938-4078              consulting@starshine.org
> Proprietor, Starshine Technical Services:  http://www.starshine.org
> 
> --
> To unsubscribe: mail -s unsubscribe pam-list-request@redhat.com < /dev/null



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