[buug] process running all the time that sucks up ... (PAM?)

[Michael Paoli]

That's not what I said.  Whether or not such process(es) exist is
generally speaking quite independent of PAM.  That you see something
like:
login [pam]
in the ps(1) listing, is just login's way of telling you it utilizes
PAM.  If it didn't you'd probably just see:
login
If you want to disable any and all processes that wait/listen for a
login, you probably could ... but then logging in would be quite a
challenge - even from the console.

Unix/Linux/BSD, etc. - multiuser multitasking operating system.  That
generally requires some means to authenticate and something that somehow
"listens", in one way or another, for such a request.

> From: "Karen Hogoboom" <khogoboom at gmail.com>
> Subject: Re: PAM (& base install of BSD)
> Date: Thu, 10 Mar 2011 17:49:52 -0800

> So, you're saying I want a process running all the time that sucks up CPU
> cycles while I'm on my own machine talking only to myself on a base install
> of BSD.
>
> On Thu, Mar 10, 2011 at 5:46 PM, Michael Paoli <
> Michael.Paoli at cal.berkeley.edu> wrote:
>
>> From: "Karen Hogoboom" <khogoboom at gmail.com>
>>> Subject: Re: login [not] a daemon? ... & CDs
>>> Date: Thu, 10 Mar 2011 06:30:13 -0800
>>>
>>
>>  I still don't see why a base install of BSD decided I wanted to use PAM.
>>>
>>
>> Because PAM is generally the right way to do it.  It rather cleanly
>> (via API) separates out most authentication, etc. from the programs
>> that need to use such.
>>
>> In the "bad old days" before PAM, if one needed to add a new
>> authentication scheme, one would have to update (e.g. recode/recompile)
>> all the programs that used authentication to support the new
>> authentication scheme.  Likewise if a bug was found in said
>> authentication scheme, all those programs would need to be updated.
>> With PAM, just the PAM modules/programs themselves would need to be
>> updated.  The concept and practice is relatively similar to shared
>> libraries in general.