Re: NSS and PAM

2003-12-01 Thread Brandon S. Allbery KF8NH
On Mon, 2003-12-01 at 21:24, Tim Kientzle wrote: > Why is the directory "usually the worst" for storing > authentication information? This one's fairly easy to answer: you want to stick authentication data into a potentially public/exposed directory? Even traditional Unix uses /etc/shadow (or mo

Re: NSS and PAM

2003-12-01 Thread Tim Kientzle
Garrett Wollman wrote: < The problem is that the authentication information needs to be stored somewhere, and the usual solution is to store it in the directory, ...which is usually the worst possible place. Please don't penalize those of us with sensible authentication systems. Care to elaborat

Re: NSS and PAM

2003-12-01 Thread Dag-Erling Smørgrav
Garrett Wollman <[EMAIL PROTECTED]> writes: > < =?iso-8859-1?q?Sm=F8rgrav?=) said: > > The problem is that the authentication information needs to be stored > > somewhere, and the usual solution is to store it in the directory, > ...which is usually the worst possible place. Please don't penalize

Re: NSS and PAM

2003-12-01 Thread Garrett Wollman
< The problem is that the authentication information needs to be stored > somewhere, and the usual solution is to store it in the directory, ...which is usually the worst possible place. Please don't penalize those of us with sensible authentication systems. -GAWollman

Re: NSS and PAM

2003-12-01 Thread Dag-Erling Smørgrav
"Jacques A. Vidrine" <[EMAIL PROTECTED]> writes: > Hmm, I disagree completely. :-) [...] You are bringing authorization into the fray... we're talking about directory services (retrieving information about a user) and authentication (identifying someone as that user), not authorization. > > Al

Re: NSS and PAM

2003-12-01 Thread Jacques A. Vidrine
On Mon, Dec 01, 2003 at 05:48:22PM +0100, Dag-Erling Smørgrav wrote: > They are different issues, but in this context you can't discuss one > without the other. Authentication doesn't work unless you have a user > to authenticate. It makes no sense to separate them; you just end up > duplicating

Re: NSS and PAM

2003-12-01 Thread Brandon S. Allbery KF8NH
On Mon, 2003-12-01 at 11:48, Dag-Erling SmÃrgrav wrote: > > If I understand you correctly, you believe that it would be possible > > to unite the NSS and PAM switches, so that they used the same > > configuration file, dynamic loading mechanisms, cascading, and so > > on. Sure, I think that's poss

Re: NSS and PAM

2003-12-01 Thread Robert Watson
On Mon, 1 Dec 2003, Dag-Erling Smørgrav wrote: > "Jacques A. Vidrine" <[EMAIL PROTECTED]> writes: > > By `the two', do you mean directory services and authentication? They > > are certainly not `essentially one'. But I suspect you know this and > > I am just misunderstanding your meaning. > > T

Re: NSS and PAM

2003-12-01 Thread Dag-Erling Smørgrav
"Jacques A. Vidrine" <[EMAIL PROTECTED]> writes: > By `the two', do you mean directory services and authentication? They > are certainly not `essentially one'. But I suspect you know this and > I am just misunderstanding your meaning. They are different issues, but in this context you can't disc

Re: NSS and PAM

2003-12-01 Thread Jacques A. Vidrine
On Sat, Nov 29, 2003 at 02:45:24AM +0100, Dag-Erling Smørgrav wrote: > "Jacques A. Vidrine" <[EMAIL PROTECTED]> writes: > > Interesting. Explain, please. (Maybe privately or in another thread; > > hate to keep this'n going.) Perhaps you mean that it is a design flaw > > that two APIs are require

Re: NSS and PAM, dynamic vs. static

2003-12-01 Thread Jacques A. Vidrine
On Sat, Nov 29, 2003 at 02:01:02PM +0100, Matthias Andree wrote: > "Jacques A. Vidrine" <[EMAIL PROTECTED]> writes: > > NSS and PAM do not overlap. > > I wonder how PAM gets "system" authentication information for pam_pwdb > or pam_unix or how it's called today and on the pertinent system if not >

Re: NSS and PAM (was Re: NSS and PAM, dynamic vs. static)

2003-11-29 Thread Richard Coleman
slave-mike wrote: why does /bin/sh need NSS support? 1. If you are using pam_ldap, tilde expansion will be broken in /bin/sh without nss_ldap support. 2. Tilde expansion is required for POSIX conformance. It's not the strongest rationale. But it's something to consider. Richard Coleman [EMAIL

Re: NSS and PAM (was Re: NSS and PAM, dynamic vs. static)

2003-11-29 Thread Dag-Erling Smørgrav
slave-mike <[EMAIL PROTECTED]> writes: > why does /bin/sh need NSS support? Because /bin/sh uses getpwnam(). We've been through this before. DES -- Dag-Erling Smørgrav - [EMAIL PROTECTED] ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mai

Re: NSS and PAM

2003-11-29 Thread Dag-Erling Smørgrav
Richard Coleman <[EMAIL PROTECTED]> writes: > Replacing passwd/group/NSS/PAM/whatever with a real database or > directory backend is a kind of holy grail for Unix that's been > discussed for many years. You're mixing apples and oranges here. NSS and PAM are not backends in themselves; they are fr

Re: NSS and PAM, dynamic vs. static

2003-11-29 Thread Matthias Andree
"Jacques A. Vidrine" <[EMAIL PROTECTED]> writes: > On Wed, Nov 26, 2003 at 02:00:08AM +0100, Matthias Andree wrote: >> Matthew Dillon <[EMAIL PROTECTED]> writes: >> >> > How much do you intend to use NSS for? I mean, what's the point of >> > adopting this cool infrastructure if all you a

Re: NSS and PAM (was Re: NSS and PAM, dynamic vs. static)

2003-11-29 Thread slave-mike
why does /bin/sh need NSS support? Jacques A. Vidrine wrote: [Threading intentionally broken.] On Sat, Nov 29, 2003 at 01:16:25AM +0100, Dag-Erling Sm?rgrav wrote: "Jacques A. Vidrine" <[EMAIL PROTECTED]> writes: NSS and PAM do not overlap. They are complimentary and one cannot do the job of th

Re: NSS and PAM

2003-11-28 Thread Richard Coleman
Dag-Erling Smørgrav wrote: NSS itself doesn't make much sense to me; it's an elaborate hack designed to drag all those nice shiny directory services down in the mud where struct passwd has been wallowing for the past twenty years, instead of allowing applications to take advantage of their superior

Re: NSS and PAM

2003-11-28 Thread Dag-Erling Smørgrav
"Jacques A. Vidrine" <[EMAIL PROTECTED]> writes: > Interesting. Explain, please. (Maybe privately or in another thread; > hate to keep this'n going.) Perhaps you mean that it is a design flaw > that two APIs are required. If so, I happen to disagree; I think that > the separation of directory s

NSS and PAM (was Re: NSS and PAM, dynamic vs. static)

2003-11-28 Thread Jacques A. Vidrine
[Threading intentionally broken.] On Sat, Nov 29, 2003 at 01:16:25AM +0100, Dag-Erling Smørgrav wrote: > "Jacques A. Vidrine" <[EMAIL PROTECTED]> writes: > > NSS and PAM do not overlap. They are complimentary and one cannot do > > the job of the other. > > That is a bug in NSS, PAM or both. Int

Re: NSS and PAM, dynamic vs. static

2003-11-28 Thread Dag-Erling Smørgrav
"Jacques A. Vidrine" <[EMAIL PROTECTED]> writes: > NSS and PAM do not overlap. They are complimentary and one cannot do > the job of the other. That is a bug in NSS, PAM or both. (BTW, I think you mean that they are complementary, not complimentary, although it is certainly true that some implem

Re: NSS and PAM, dynamic vs. static (was: 40% slowdown with dynamic /bin/sh)

2003-11-26 Thread Jacques A. Vidrine
On Wed, Nov 26, 2003 at 02:00:08AM +0100, Matthias Andree wrote: > Matthew Dillon <[EMAIL PROTECTED]> writes: > > > How much do you intend to use NSS for? I mean, what's the point of > > adopting this cool infrastructure if all you are going to do with it > > is make a better PAM out

Re: NSS and PAM, dynamic vs. static (was: 40% slowdown with dynamic /bin/sh)

2003-11-25 Thread Matthias Andree
On Tue, 25 Nov 2003, David O'Brien wrote: > On Wed, Nov 26, 2003 at 02:00:08AM +0100, Matthias Andree wrote: > > As a user, I like /rescue better than the step-child that /stand/* used > > to be. It's part of the world, which /stand wasn't. > > Except that we still have /stand. It should be shot

Re: NSS and PAM, dynamic vs. static (was: 40% slowdown with dynamic /bin/sh)

2003-11-25 Thread David O'Brien
On Wed, Nov 26, 2003 at 02:00:08AM +0100, Matthias Andree wrote: > As a user, I like /rescue better than the step-child that /stand/* used > to be. It's part of the world, which /stand wasn't. Except that we still have /stand. It should be shot, but some won't let it go... ___