Re: NSS and PAM, dynamic vs. static
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 through NSS. Reimplementation of these passwd/shadow/whatever mechanisms? No, PAM uses the system directory services APIs (e.g. getpwnam(3) and similar). Those in turn use NSS, on NSS systems. Cheers, -- Jacques Vidrine NTT/Verio SME FreeBSD UNIX Heimdal [EMAIL PROTECTED] [EMAIL PROTECTED] [EMAIL PROTECTED] [EMAIL PROTECTED] ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: NSS and PAM
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 required. If so, I happen to disagree; I think that the separation of directory services and authentication is appropriate and necessary. No, the two are essentially one. We just think they aren't because we've been brainwashed to think of users in terms of uids and gids and especially struct passwd, which deserves to die. 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. 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 functionality. I guess I think of it this way. If NSS had not been implemented `down in the mud' (inside getpw*, getgr*, gethostby*, etc.), then applications that used the UNIX directory service APIs would need to be re-written in order to utilize NSS. That's a lot of code to change for little benefit. PAM is different. Applications *had* to be re-written to utilize PAM, because previously there was no real authentication API, just crypt() and strcmp()--- obviously insufficient for many authentication methods :-) As for PAM, a lot of what's wrong with it today could be fixed by redesigning it to include directory services. If you fixed the conversation system (by formalizing service function execution as an FSM) and cleaned up the configuration syntax, you'd end up with something quite nice. 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 possible. There might even be some benefit, though probably not enough benefit to abandon PAM/NSS and go our own way. Cheers, -- Jacques Vidrine NTT/Verio SME FreeBSD UNIX Heimdal [EMAIL PROTECTED] [EMAIL PROTECTED] [EMAIL PROTECTED] [EMAIL PROTECTED] ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: NSS and PAM
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 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 a lot of concepts and code. Also, is changing your password an authentication function or a directory function? I don't think you can answer either without answering both. I guess I think of it this way. If NSS had not been implemented `down in the mud' (inside getpw*, getgr*, gethostby*, etc.), then applications that used the UNIX directory service APIs would need to be re-written in order to utilize NSS. That's a lot of code to change for little benefit. Backward compatibility is fine, but NSS does not seem to export an API that we can use when we want to lift ourselves out of the mud, so we are forced to keep rooting around in it. One consequence of this (and of the artificial separation between NSS and PAM) is that passwd(1) doesn't work properly except in the simplest cases. 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 possible. There might even be some benefit, though probably not enough benefit to abandon PAM/NSS and go our own way. Not to go our own way, no. There's the rub. It would have to be a reasonably wide effort; we'd need to get at least one major Linux distro to adopt the same infrastructure. DES -- Dag-Erling Smørgrav - [EMAIL PROTECTED] ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: NSS and PAM
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. 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 a lot of concepts and code. Also, is changing your password an authentication function or a directory function? I don't think you can answer either without answering both. It strikes me that there are two separate issues: (1) Whether or not there's a useful distinction between authentication services and directory services. (2) If there is or isn't such a distinction in (1), whether or not that distinction should appear in the implementation. In practice, people frequently mix and match authentication services and directory services, and there are services that implement one but not the other. For example, Kerberos5 for authentication an LDAP for directory services is a common combination: however, Kerberos doesn't provide directory services, only principal authentication. Likewise, even on purely local systems, the account directory services (pwent, et al) may be distinct from principal authentication using one-time passwords, etc. I'm not opposed to the fundamental idea of combining mechanism, but there are some practical underlying differences between directory services and authentication, even though there's clear overlap. Robert N M Watson FreeBSD Core Team, TrustedBSD Projects [EMAIL PROTECTED] Senior Research Scientist, McAfee Research ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: NSS and PAM
On Mon, 2003-12-01 at 11:48, Dag-Erling Smrgrav 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 possible. There might even be some benefit, though probably not enough benefit to abandon PAM/NSS and go our own way. Not to go our own way, no. There's the rub. It would have to be a reasonably wide effort; we'd need to get at least one major Linux distro to adopt the same infrastructure. Has anyone considered the idea of hybridizing PAM with Digital^WCompaq^WHP's SIA matrix setup? -- brandon s. allbery[linux,solaris,freebsd,perl] [EMAIL PROTECTED] system administrator [WAY too many hats][EMAIL PROTECTED] electrical and computer engineering, carnegie mellon univ. KF8NH ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: NSS and PAM
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 a lot of concepts and code. Hmm, I disagree completely. :-) They can be separated and should be separated. Systems that mix them up are flawed. The confusion of the two are what *causes* the problem you bring up below (passwd(1)). Authentication simply names you. It is quite possible to be authenticated in some context and have absolutely no privileges or other information (``in a vacuum'', if you will). It is even useful in some cases: = `Junk' certificates = `Junk' Kerberos principals = A disabled account = A newly-created account More practically speaking, the mechanism by which you authenticate usually has no bearing on what you are authorized to do. This is the power of properly separating authentication and authorization: regardless of whether I authenticate by entering my password, inserting my smart card and PIN, or supplying a Kerberos ticket, my privileges will be the same [1]. Similarly, if the IT department moved from NIS to LDAP over the weekend, all my existing authentication tokens naturally still work. That's not to say that you *cannot* combine authentication and authorization, but they are naturally independent and different protocols and semantics are required for one and the other. RADIUS is a good example. It is quite difficult to properly support a variety of authentication mechanisms in RADIUS. Diameter addresses the issue by supporting a separate authentication protocol, EAP, which in turn allows for various authentication mechanisms generically. Also, is changing your password an authentication function or a directory function? I don't think you can answer either without answering both. I think it is strictly an authentication function. The change in your password has no affect on your UID, or your phone number, or in what ACLs your name appears in. I guess I think of it this way. If NSS had not been implemented `down in the mud' (inside getpw*, getgr*, gethostby*, etc.), then applications that used the UNIX directory service APIs would need to be re-written in order to utilize NSS. That's a lot of code to change for little benefit. Backward compatibility is fine, but NSS does not seem to export an API that we can use when we want to lift ourselves out of the mud, so we are forced to keep rooting around in it. What's an example of what you mean? The BSD nsswitch implementation has a generic nsdispatch(3) that allows for new applications, but I'm not sure that is what you mean. At any rate, it is not `NSS' proper, it is an implementation detail. One consequence of this (and of the artificial separation between NSS and PAM) is that passwd(1) doesn't work properly except in the simplest cases. It seems to me that this is a direct result of passwd(1) confusing authentication and authorization. Other than determining the default target user name from the current UID, passwd(1) needs only to invoke PAM interfaces to change your password for any authentication method that supports password changing. Of course this won't work for certain legacy, read-mostly `authentication methods' such as NIS or Hesiod that aren't supported by PAM. 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 possible. There might even be some benefit, though probably not enough benefit to abandon PAM/NSS and go our own way. Not to go our own way, no. There's the rub. It would have to be a reasonably wide effort; we'd need to get at least one major Linux distro to adopt the same infrastructure. Indeed, ``there's the rub'' :-) Cheers, -- Jacques Vidrine NTT/Verio SME FreeBSD UNIX Heimdal [EMAIL PROTECTED] [EMAIL PROTECTED] [EMAIL PROTECTED] [EMAIL PROTECTED] [1] Mostly. An application might require that you used a strong authentication method, to launch the nukes or something. :-) ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: NSS and PAM
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. Also, is changing your password an authentication function or a directory function? I don't think you can answer either without answering both. I think it is strictly an authentication function. The change in your password has no affect on your UID, or your phone number, or in what ACLs your name appears in. The problem is that the authentication information needs to be stored somewhere, and the usual solution is to store it in the directory, so changing the password involves both authentication and directory services. Backward compatibility is fine, but NSS does not seem to export an API that we can use when we want to lift ourselves out of the mud, so we are forced to keep rooting around in it. What's an example of what you mean? The BSD nsswitch implementation has a generic nsdispatch(3) that allows for new applications, but I'm not sure that is what you mean. At any rate, it is not `NSS' proper, it is an implementation detail. Like you say, it is an implementation detail, and it is far too low-level to be of use. We need an API that retrieves information about a user according to rules established by the administrator (nsswitch.conf or pam.conf or whatever) and is flexible enough to handle the fact that different directories store different amounts of information about the users at different levels of detail (for instance, LDAP stores first and last name separately while /etc/passwd only has the one GCOS field). It seems to me that this is a direct result of passwd(1) confusing authentication and authorization. Other than determining the default target user name from the current UID, passwd(1) needs only to invoke PAM interfaces to change your password for any authentication method that supports password changing. No, because PAM doesn't control retrieval of the user information. If it did, it would be as simple as you say, but it doesn't - NSS does - so it's a nightmare. Imagine the case where different directories contain different entries for the same user, or for different users who happen to have the same name; this is standard practice with NIS. Which directory do you write the modified entry into? The obvious answer is the one it came out of in the first place, but PAM doesn't know which one that was. DES -- Dag-Erling Smørgrav - [EMAIL PROTECTED] ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: NSS and PAM
On Mon, 01 Dec 2003 23:24:40 +0100, [EMAIL PROTECTED] (Dag-Erling =?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 those of us with sensible authentication systems. -GAWollman ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: NSS and PAM
Garrett Wollman [EMAIL PROTECTED] writes: On Mon, 01 Dec 2003 23:24:40 +0100, [EMAIL PROTECTED] (Dag-Erling =?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 those of us with sensible authentication systems. You're the one trying to penalize other people. A common framework for directory and authentication services can of course store authentication tokens separately from user information, but the reverse isn't true. You can't unilaterally decide to leave out functionality that 90% of our users require just because you are in a position to use (what you consider to be) a better solution. DES -- Dag-Erling Smørgrav - [EMAIL PROTECTED] ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: NSS and PAM
Garrett Wollman wrote: On Mon, 01 Dec 2003 23:24:40 +0100, [EMAIL PROTECTED] (Dag-Erling =?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 those of us with sensible authentication systems. Care to elaborate, Garrett? I've been following this discussion with some interest, and would like to see people elucidate their positions and concerns. Both DES and Jacques have made some interesting points so far. What exactly is your sensible authentication system? Why is the directory usually the worst for storing authentication information? What do you think are the correct fracture points and how do they relate to the existing PAM/NSS frameworks? Tim ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: NSS and PAM
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 more complex solutions on some commercial systems) these days, so the password isn't in the directory (/etc/passwd). However, I have to agree with des's argument: a combined matrix for directory and authentication services doesn't mean the *data* must be combined. Using (for example) SIA, one could specify Kerberos 5 (my guess as to wollman's better answer) and LDAP, and simply not specify entry points for the parts that each doesn't handle (Kerberos doesn't support directory services, and LDAP isn't being used for authentication), with later entries falling back to NIS or traditional files. But this arrangement allows traditional APIs to work reasonably --- and you can layer PAM and NSS on top of it as compatibility APIs. -- brandon s. allbery[linux,solaris,freebsd,perl] [EMAIL PROTECTED] system administrator [WAY too many hats][EMAIL PROTECTED] electrical and computer engineering, carnegie mellon univ. KF8NH ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: NSS and PAM (was Re: NSS and PAM, dynamic vs. static)
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 the other. That is a bug in NSS, PAM or both. 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 services and authentication is appropriate and necessary. (BTW, I think you mean that they are complementary, not complimentary, although it is certainly true that some implementations of NSS and PAM are free) heh, Yes, that's a spell-o from which spell-check could not save me. Cheers, -- --- I'm a UNIX Kinda Guy. My websites: http://slavepix.dyns.net/ http://jaxleather.dyns.net/ ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: NSS and PAM, dynamic vs. static
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 are going to do with it is make a better PAM out of it? The important thing is that NSS allows to plug modules such as LDAP or PostgreSQL for user base management. PAM is only halfway there and doesn't give libc et al. a notion of a user or group context (in spite of its account context), NSS does. One might discuss if PAM is really needed with NSS in place, but it's hard to think of a system without NSS and removing PAM now doesn't look right. 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 through NSS. Reimplementation of these passwd/shadow/whatever mechanisms? -- Matthias Andree Encrypt your mail: my GnuPG key ID is 0x052E7D95 ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: NSS and PAM
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 frameworks that allow the admin to select and combine directory and authentication backends and policies. You can't get by without them, because you will never find a single solution that can replace the entire installed base of LDAP, Radius, TAC+, Kerberos etc., and you can't enforce policy from the backend. DES -- Dag-Erling Smørgrav - [EMAIL PROTECTED] ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: NSS and PAM (was Re: NSS and PAM, dynamic vs. static)
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/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: NSS and PAM (was Re: NSS and PAM, dynamic vs. static)
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 PROTECTED] ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: NSS and PAM, dynamic vs. static
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 implementations of NSS and PAM are free) DES -- Dag-Erling Smørgrav - [EMAIL PROTECTED] ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
NSS and PAM (was Re: NSS and PAM, dynamic vs. static)
[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. 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 services and authentication is appropriate and necessary. (BTW, I think you mean that they are complementary, not complimentary, although it is certainly true that some implementations of NSS and PAM are free) heh, Yes, that's a spell-o from which spell-check could not save me. Cheers, -- Jacques Vidrine NTT/Verio SME FreeBSD UNIX Heimdal [EMAIL PROTECTED] [EMAIL PROTECTED] [EMAIL PROTECTED] [EMAIL PROTECTED] ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: NSS and PAM
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 services and authentication is appropriate and necessary. No, the two are essentially one. We just think they aren't because we've been brainwashed to think of users in terms of uids and gids and especially struct passwd, which deserves to die. 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 functionality. As for PAM, a lot of what's wrong with it today could be fixed by redesigning it to include directory services. If you fixed the conversation system (by formalizing service function execution as an FSM) and cleaned up the configuration syntax, you'd end up with something quite nice. DES -- Dag-Erling Smørgrav - [EMAIL PROTECTED] ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: NSS and PAM
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 functionality. As for PAM, a lot of what's wrong with it today could be fixed by redesigning it to include directory services. If you fixed the conversation system (by formalizing service function execution as an FSM) and cleaned up the configuration syntax, you'd end up with something quite nice. DES 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. I would love to see it happen. But I doubt it could ever happen within a collaborative project like FreeBSD, since it would be impossible to get enough people to agree upon the innumerable small details. I don't want to sound so pessimistic, but I think that's just a reality of group projects. I think this is part of the reason that many people are passionate about the dynamic library implementation of PAM/NSS. We realize that the odds are very high that the alternatives will be endlessly discussed, but never implemented. Since this is a feature that many of us really need, we prefer the less than perfect but existing implementation to the perfect, but never implemented solution. This discussion has really reminded me of the classic paper by Richard Gabriel on Lisp: Good News, Bad News, How to Win Big. This is one of the best essays on the Worse is Better phenomenon. http://www.ai.mit.edu/docs/articles/good-news/good-news.html http://www.dreamsongs.com/WorseIsBetter.html Richard Coleman [EMAIL PROTECTED] ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: NSS and PAM, dynamic vs. static (was: 40% slowdown with dynamic /bin/sh)
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 of it? The important thing is that NSS allows to plug modules such as LDAP or PostgreSQL for user base management. PAM is only halfway there and doesn't give libc et al. a notion of a user or group context (in spite of its account context), NSS does. One might discuss if PAM is really needed with NSS in place, but it's hard to think of a system without NSS and removing PAM now doesn't look right. NSS and PAM do not overlap. They are complimentary and one cannot do the job of the other. Cheers, -- Jacques Vidrine NTT/Verio SME FreeBSD UNIX Heimdal [EMAIL PROTECTED] [EMAIL PROTECTED] [EMAIL PROTECTED] [EMAIL PROTECTED] ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
NSS and PAM, dynamic vs. static (was: 40% slowdown with dynamic /bin/sh)
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 of it? The important thing is that NSS allows to plug modules such as LDAP or PostgreSQL for user base management. PAM is only halfway there and doesn't give libc et al. a notion of a user or group context (in spite of its account context), NSS does. One might discuss if PAM is really needed with NSS in place, but it's hard to think of a system without NSS and removing PAM now doesn't look right. Of course, you can stuff the whole NSS client side (thinking IPC) into a statically linked executable. To stall this discussion: I don't mind if NSS is dynamically or statically linked. I won't let this drift into any other dynamic - static discussion. reason that I can see, and coming up with all sorts of extra junk, like /rescue, to work around that fact. 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. One word of warning: there used to be SuSE Linux versions that wouldn't let you log in single-user mode when the system was using NIS in multi-user because there was nothing to communicate with through AF_UNIX sockets yet this was expected to be able to log in. There are potholes and pitfalls that I consider major considered with a dynamic /bin /sbin setup. Watch out. -- Matthias Andree Encrypt your mail: my GnuPG key ID is 0x052E7D95 ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: NSS and PAM, dynamic vs. static (was: 40% slowdown with dynamic /bin/sh)
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... ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: NSS and PAM, dynamic vs. static (was: 40% slowdown with dynamic /bin/sh)
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, but some won't let it go... We have it, it's buggy (I didn't bother to report it tried to create a 5th primary partition and shot all my extended partitions in turn yet) and unbeloved -- but it doesn't get built when you type make buildworld, which is what my phrase was about. Sorry if I was unclear. Maybe FreeBSD should just use Linux' fdisk which works fine and would need only minor BSD label polishing, if any. License permitting (-: -- Matthias Andree Encrypt your mail: my GnuPG key ID is 0x052E7D95 ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
