[buug] process running all the time that sucks up ... (PAM?)
Michael.Paoli at cal.berkeley.edu
Thu Mar 10 18:06:34 PST 2011
That's not what I said. Whether or not such process(es) exist is
generally speaking quite independent of PAM. That you see something
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:
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.
More information about the buug