PAM
in [Slackware]
|
Prev: Error in script execution
Next: Kmail and LDAP support
From: Steven Saner on 13 Mar 2006 10:52 I've been using Slackware for years and I like it a lot. One thing I've wondered and have never heard is the reasons behind choosing not to use PAM for authentication. It doesn't bother me really, although I suppose it could make certain things a little easier. I am mostly just curious what the reasons are? Is it performance issues, stability, security, others? It seems that most other distros that I have come across do build authentication around PAM. Steve
From: Thomas Overgaard on 13 Mar 2006 12:05 Steven Saner wrote : > One thing I've wondered and have never heard is the reasons behind > choosing not to use PAM for authentication. PAM is missing because Patrick Volkerding never really liked it, in his opinion PAM is insecure and badly coded. -- Thomas O. This area is designed to become quite warm during normal operation.
From: Henrik Carlqvist on 13 Mar 2006 12:22 Steven Saner <ssaner(a)pantheranet.com> wrote: > One thing I've wondered and have never heard is the reasons behind > choosing not to use PAM for authentication. From ftp://ftp.slackware.com/pub/slackware/slackware-9.1/ChangeLog.txt : -8<--------------------------------------------------- Tue Sep 23 21:57:32 PDT 2003 In record time, this is Slackware 9.1 release candidate 2. :-) gnome/gal2-1.99.10-i486-1.tgz: Upgraded to gal-1.99.10. gnome/gdm-2.4.4.2-i486-1.tgz: Upgraded to gdm-2.4.4.2. gnome/gnome-applets-2.4.1-i486-1.tgz: Upgraded to gnome-applets-2.4.1. n/openssh-3.7.1p2-i486-1.tgz: Upgraded to openssh-3.7.1p2. This fixes security problems with PAM authentication. It also includes several code cleanups from Solar Designer. Slackware does not use PAM and is not vulnerable to any of the fixed problems. Please indulge me for this brief aside (as requests for PAM are on the rise): If you see a security problem reported which depends on PAM, you can be glad you run Slackware. I think a better name for PAM might be SCAM, for Swiss Cheese Authentication Modules, and have never felt that the small amount of convenience it provides is worth the great loss of system security. We miss out on half a dozen security problems a year by not using PAM, but you can always install it yourself if you feel that you're missing out on the fun. (No, don't do that) OK, I'm done ranting here. :-) I suppose this is still a: (* Security fix *) -8<--------------------------------------------------- regards Henrik -- The address in the header is only to prevent spam. My real address is: hc8(at)uthyres.com Examples of addresses which go to spammers: root(a)variousus.net root(a)localhost
From: Grant on 13 Mar 2006 18:38 On Mon, 13 Mar 2006 19:02:51 +0000 (UTC), Daniel de Kok <daniel(a)daffy.nowhere> wrote: >Filesystem ACLs are supported out of the box on Slack with kernel >2.6 :). Filesystem ACLs are actually not that bad, and a useful >extension. My impression is that ACLs are only there for windoze (server) computability and for sys-admins can't manage their user-base -the unix way- ;) >- udev Little choice about udev, sysfs + udev seem to be the only game in town and the look like a dog's breakfast. Maintainers let the thing grow randomly with arbitrary rules (one file, one value[1]) then stomp problems as they arise-- there seems to be no design process. (IOW, no requirements analysis leading to design document) Currently udev has problems uniquely describing PnP hardware, so they gonna throw a string of possibilities out to user-space so it can figure out what to do ... not promising? Grant. -- Testing can show the presense of bugs, but not their absence. -- Dijkstra
From: Keith Keller on 13 Mar 2006 19:13
On 2006-03-13, Grant <bugsplatter(a)gmail.com> wrote: > On Mon, 13 Mar 2006 19:02:51 +0000 (UTC), Daniel de Kok <daniel(a)daffy.nowhere> wrote: > >>Filesystem ACLs are supported out of the box on Slack with kernel >>2.6 :). Filesystem ACLs are actually not that bad, and a useful >>extension. > > My impression is that ACLs are only there for windoze (server) > computability and for sys-admins can't manage their user-base > -the unix way- ;) I don't actually use ACLs in my admin work, but I can see a definite use for them even in the nonWindows world. Sometimes management with the traditional user/group/other model is unwieldy, where an ACL would solve the given issue in a straightforward manner. Consider one possible example: two groups exist, groupa and groupb, and you wish to grant all members of both groups write access to /home/groupab. With the traditional model, you need to create a new group, groupab, and manually add all members of groupa and groupb to group groupab. Then, when groupa changes, you also need to update groupab. With ACLs, it's easy: grant write to groupa and to groupb separately: no separate group or group maintenance is needed. And this is a fairly trivial example; I'm sure there are other more complex examples where ACLs would be easy and ugo difficult. --keith -- kkeller-usenet(a)wombat.san-francisco.ca.us (try just my userid to email me) AOLSFAQ=http://wombat.san-francisco.ca.us/cgi-bin/fom see X- headers for PGP signature information |