PAM, depreciated-modules guidance requested (not x-posted)

MarkFilipak · 10-04-2009, 10:17 AM

I'm a newbie. My Linux is CentOS-4.4 by way of RHEL-4.4. My PAM is PAM-1.0

As of PAM-1.1.0, The following modules have been depreciated:

pam_chroot.so
pam_console.so
pam_postgresok.so
pam_pwdb.so
pam_rhosts_auth.so
pam_rps.so
pam_smbpass.so
pam_stack.so
pam_unix_acct.so
pam_unix_auth.so
pam_unix_passwd.so
pam_unix_session.so
pam_winbind.so

and the following modules have been added:

pam_echo.so
pam_exec.so
pam_faildelay.so
pam_namespace.so
pam_pwhistory.so
pam_rhosts.so
pam_sepermit.so
pam_tty_audit.so
pam_umask.so

My concern is that I have "pam_stack.so" in module stacks throughout /etc/pam.d/. Of particular concern is /etc/pam.d/sshd.

Questions:

Q1: Where should I go for help with server security maintenance (especially, PAM)?
Q2: When will people learn that "depreciate" and "deprecate" are two, entirely different words?
Q3: Why doesn't the NEWS or README files in the PAM-1.1.0 distribution say anything about this?
Q4: Is this something about which I should be concerned?
Q5: Being a newbie, of what other things am I blithely ignorant?

Q6: Is there any way to search the forums (e.g., Linux - Newbie) for keywords like "PAM" and "depreciated"?

Thanks folks! Love ya! Ciao -- Mark

chrism01 · 10-04-2009, 07:48 PM

Q1/Q6. given you've got Centos, look around here (use the advanced search fn) also, the web and, at the moment, the RH Knowledge Base is open to all.
Q2. prob around the time they can differentiate between effect & affect ... sigh ...
Q3. PASS
Q4. Deprecate (as you may know) just means it won't be supported in future, but still works for now.
FYI, I believe it's been replaced by the 'include' directive eg
http://www.linuxtopia.org/online_boo...l5_ch-pam.html
http://www.kernel.org/pub/linux/libs...tion-file.html
http://linux.die.net/man/8/pam_stack
(You do know current RHEL is 5.4 and Centos will be the same shortly?)
Q5. Hmmm, tricky, I don't think we can read your mind to find out what's missing..

You'll just have to ask qns as & when they occur to you.

Welcome to LQ

MarkFilipak · 10-05-2009, 04:21 PM

Thanks for the links.

Quote:

Originally Posted by chrism01

Deprecate (as you may know) just means it won't be supported in future, but still works for now.

Ummm... no it doesn't.

Deprecate: To feel and express disapproval of; plead against.

Depreciate: To reduce in value or price.

Depreciate means it won't be supported in future, but still works for now.

Deprecate means to express disapproval (e.g., of people who don't know that the correct word is "depreciate"), as I am here doing.

Ciao -- Mark

PS: Actually, in this case, the modules are GONE! - they are not in the distribution - so I suppose they are not depreciated, but have been removed. So, what should I do? Worry? Ignore? -- M.

lutusp · 10-05-2009, 05:18 PM

Quote:

Originally Posted by MarkFilipak

As of PAM-1.1.0, The following modules have been depreciated: ...

No, they have not been depreciated, they have been deprecated. In your Google searches and other text-based activities, you are handicapping yourself by misspelling this word.

s/depreciated/deprecated/

blackhole54 · 10-05-2009, 05:30 PM

Quote:

Originally Posted by MarkFilipak

Q2: When will people learn that "depreciate" and "deprecate" are two, entirely different words?

Interesting question. I have no idea.

A related question that might be interesting is when will people learn that some words have technical meanings or special meanings that apply in certain fields of endeavor.

Since you rejected MarkFilipak's gentle tutelage (oops -- I did mean chrism01's gentle tutelage), I draw your attention to the following web pages:

http://www.d.umn.edu/itss/support/Tr...lossary/d.html
http://en.wikipedia.org/wiki/Deprecate

Read and learn ...

Quote:

Q5: Being a newbie, of what other things am I blithely ignorant?

Such an open-ended question ...

Quote:

Q6: Is there any way to search the forums (e.g., Linux - Newbie) for keywords like "PAM" and "depreciated"?

There are search links at the top of this page and to the left. If you want to restrict the search to a particular forum you will need "advanced search." The link on the left automatically gives you advanced search.

You will probably have better luck with a search if you use the correct term (deprecate) rather than "depreciate." But that's just a guest ...

chrism01 · 10-05-2009, 08:23 PM

www.dictionary.com

Quote:

Deprecate:

Computer Science; To mark (a component of a software standard) as obsolete to warn against its use in the future so that it may be phased out.

It's a well known technical definition.

MarkFilipak · 10-05-2009, 11:51 PM

WOW!! I humbly beg forgiveness.

I've been in this racket for - what? - over 20 years and I've been using the wrong word. "Depreciate" seems like the better word, but if the rest of the meta-world is using "deprecate", then by golly I'm going to use "deprecate".

Thank you. I've learned something useful from this forum already.

(It reminds me that when I was a kid, having never heard the word "diplodocus" pronounced, I thought it was dip-lih-DOAK-us. The first time I said it in a natural history museum left the people around me ROFL. - and that story, dear friends, is self-deprecation.-)

Kennedymark · 10-06-2009, 12:17 AM

Really a educative and informative post, the post is good in all regards,I am glad to read this post.

MarkFilipak · 10-06-2009, 01:41 AM

And now, back to our regularly scheduled program, in progress...

In PAM-1.1.0, pam_stack.so has been, not depreciated, not even deprecated, but removed. So, now what? (And please don't respond with Welcome to the wonderful world of server maintenance.)

Is there some discussion forum (as opposed to this questions forum) where such things are handled? As a newbie, I'm not quite ready to run down the down escalator - I'm not too keen to debug a PAM auth stack.

Thanks all. Ciao -- Mark

PS: Hey Kennedymark: Welcome to the Linux Questions forum. "Looking-to-Buy-Resveratrol-Ultra-Pure-Online", eh? Do they sell Spam?

chrism01 · 10-06-2009, 01:58 AM

As per my orig post & links. I believe it's replaced by the 'include' directive.
You include another file and PAM jumps to that file (like a fn/sub) works through it, then rtns to where it left off.
A bit like Apache include dirs if that helps (or not)

MarkFilipak · 10-06-2009, 02:19 AM

Quote:

Originally Posted by chrism01

As per my orig post & links. I believe it's replaced by the 'include' directive.
You include another file and PAM jumps to that file (like a fn/sub) works through it, then rtns to where it left off.
A bit like Apache include dirs if that helps (or not)

Thanks. I did know about "include". But there are serious considerations in their use. For example:

Code:

auth   [perm_denied=1]   <some-pam-module>
auth   required   pam_stack.so service=system-auth
auth   required   pam_deny.so

(which stipulates that if <some-pam-module> returns "perm_denied", then skip one line (which entirely skips the "pam_stack.so service=system-auth" line)), whereas this:

Code:

auth   [perm_denied=1]   <some-pam-module>
auth   include   system-auth
auth   required   pam_deny.so

(which will skip only the first line of system-auth on "perm_denied") will behave very differently (possibly resulting in a security hole). Thus, the need to test the auth stack.

Before you protest that my example is not realistic, I agree, but I have read that there are some subtle details to using "include" that are non-obvious regarding "bad" vs. "die" for example, or the change from "required" in the original 'call' to pam_stack.so vs. whatever status is actually returned by system-auth.

I don't think - I may be wrong - that this forum is suited to this sort of discussion. Am I right or wrong? Please advise. Ciao -- Mark

PS (edit):
Never mind. I just discovered the Linux - Server forum, right here. I guess I shouldn't be in Newbies. BTW, the issue has not been discussed there. (Actually, not much is discussed there - seems like this is not a discussion board.) Anybody know of a Server Maintenance Discussion Board? -- M.