Re: docs/12377: doc patch for login_cap.
On Fri, Jul 09, 1999 at 11:39:38AM +0200, Sheldon Hearn wrote: On Thu, 08 Jul 1999 20:59:58 +0100, Nik Clayton wrote: With that in mind, how about this patch (in conjunction with the patch to login.conf in the original PR, which just updates a comment)? This looks much better. :-) Committing it now. N -- [intentional self-reference] can be easily accommodated using a blessed, non-self-referential dummy head-node whose own object destructor severs the links. -- Tom Christiansen in [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: docs/12377: doc patch for login_cap.
On Fri, Jul 09, 1999 at 11:39:38AM +0200, Sheldon Hearn wrote: On Thu, 08 Jul 1999 20:59:58 +0100, Nik Clayton wrote: With that in mind, how about this patch (in conjunction with the patch to login.conf in the original PR, which just updates a comment)? This looks much better. :-) Committing it now. N -- [intentional self-reference] can be easily accommodated using a blessed, non-self-referential dummy head-node whose own object destructor severs the links. -- Tom Christiansen in 37514...@cs.colorado.edu To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-hackers in the body of the message
Re: docs/12377: doc patch for login_cap.
On Thu, 08 Jul 1999 20:59:58 +0100, Nik Clayton wrote: With that in mind, how about this patch (in conjunction with the patch to login.conf in the original PR, which just updates a comment)? This looks much better. :-) Ciao, Sheldon. To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: docs/12377: doc patch for login_cap.
On Thu, 08 Jul 1999 20:59:58 +0100, Nik Clayton wrote: With that in mind, how about this patch (in conjunction with the patch to login.conf in the original PR, which just updates a comment)? This looks much better. :-) Ciao, Sheldon. To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-hackers in the body of the message
Re: docs/12377: doc patch for login_cap.
On Thu, 08 Jul 1999 00:03:10 +0100, Nik Clayton wrote: I have done. As far as I can tell, the submitter is saying "Yes, the information I was looking for was in the manual page, but it (specifically, that the "root" account doesn't use the "default" entry) is buried as a throw away comment at the end of a long paragraph." No. The PR suggests a fix to a completely different paragraph, describing a different function. Ciao, Sheldon. To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: docs/12377: doc patch for login_cap.
Nope, I did read the docs, hence the patch to the manpage to make it stand out more clearly. I still am of the opinion that "default" should mean "default" for everyone. AFIK, there are no other fields in passwd that have different interpretations/defaults depending upon the UID. This is why I made my remarks about this being a violation of the principle of least surprise. My PR took the very conservative approach of just amplifying the documentation rather than making any funictional changes whatsoever. If a patch that make "default" the true default for all user and then explicitly set root's default class to 'root' would be accepted, I am willing to provide one. IMHO, this would be cleaner. The semantics of multiple default values boggles my mind. cheers, Adrian -- [ [EMAIL PROTECTED] -- Ubergeeks Consulting -- http://www.ubergeeks.com/ ] On Tue, 6 Jul 1999, Sheldon Hearn wrote: On Mon, 05 Jul 1999 23:56:17 +0100, Nik Clayton wrote: I'm unfamiliar with the ins and outs of the login_cap system. Could someone who is versed in it please take a look at this PR (text included) and let me know whether or not the suggested patch is correct. Quite often, we receive requests to improve documentation that are born out of a failure to read that documentation correctly. I think this PR might be one of those cases. Have a look at the login_cap(3) manpage, into which I suspect the submitter may not have dug deeply enough: The functions login_getpwclass(), login_getclass() and login_getuserclass() retrieve the applicable login class record for the user's passwd entry or class name by calling login_getclassbyname(). On failure, NULL is returned. The difference between these functions is that login_getuserclass() includes the user's overriding .login_conf that exists in the user's home directory, login_getpwclass,() and login_getclass() restricts loookup only to the system login class database in /etc/login.conf. login_getpwclass() only differs from login_getclass() in that it allows the default class for user 'root' as "root" if none has been specified in the password database. Otherwise, if the passwd pointer is NULL, or the user record has no login class, then the system "default" entry is retrieved. Regards, Sheldon. To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message Adrian -- [ [EMAIL PROTECTED] -- Ubergeeks Consulting -- http://www.ubergeeks.com/ ] To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: docs/12377: doc patch for login_cap.
On Thu, 08 Jul 1999 00:03:10 +0100, Nik Clayton wrote: I have done. As far as I can tell, the submitter is saying Yes, the information I was looking for was in the manual page, but it (specifically, that the root account doesn't use the default entry) is buried as a throw away comment at the end of a long paragraph. No. The PR suggests a fix to a completely different paragraph, describing a different function. Ciao, Sheldon. To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-hackers in the body of the message
Re: docs/12377: doc patch for login_cap.
Nope, I did read the docs, hence the patch to the manpage to make it stand out more clearly. I still am of the opinion that default should mean default for everyone. AFIK, there are no other fields in passwd that have different interpretations/defaults depending upon the UID. This is why I made my remarks about this being a violation of the principle of least surprise. My PR took the very conservative approach of just amplifying the documentation rather than making any funictional changes whatsoever. If a patch that make default the true default for all user and then explicitly set root's default class to 'root' would be accepted, I am willing to provide one. IMHO, this would be cleaner. The semantics of multiple default values boggles my mind. cheers, Adrian -- [ adr...@ubergeeks.com -- Ubergeeks Consulting -- http://www.ubergeeks.com/ ] On Tue, 6 Jul 1999, Sheldon Hearn wrote: On Mon, 05 Jul 1999 23:56:17 +0100, Nik Clayton wrote: I'm unfamiliar with the ins and outs of the login_cap system. Could someone who is versed in it please take a look at this PR (text included) and let me know whether or not the suggested patch is correct. Quite often, we receive requests to improve documentation that are born out of a failure to read that documentation correctly. I think this PR might be one of those cases. Have a look at the login_cap(3) manpage, into which I suspect the submitter may not have dug deeply enough: The functions login_getpwclass(), login_getclass() and login_getuserclass() retrieve the applicable login class record for the user's passwd entry or class name by calling login_getclassbyname(). On failure, NULL is returned. The difference between these functions is that login_getuserclass() includes the user's overriding .login_conf that exists in the user's home directory, login_getpwclass,() and login_getclass() restricts loookup only to the system login class database in /etc/login.conf. login_getpwclass() only differs from login_getclass() in that it allows the default class for user 'root' as root if none has been specified in the password database. Otherwise, if the passwd pointer is NULL, or the user record has no login class, then the system default entry is retrieved. Regards, Sheldon. To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-hackers in the body of the message Adrian -- [ adr...@ubergeeks.com -- Ubergeeks Consulting -- http://www.ubergeeks.com/ ] To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-hackers in the body of the message
Re: docs/12377: doc patch for login_cap.
Sheldon, On Thu, Jul 08, 1999 at 10:23:06AM +0200, Sheldon Hearn wrote: I have done. As far as I can tell, the submitter is saying Yes, the information I was looking for was in the manual page, but it (specifically, that the root account doesn't use the default entry) is buried as a throw away comment at the end of a long paragraph. No. The PR suggests a fix to a completely different paragraph, describing a different function. OK. I've looked at this in more detail, and it seems as though two functions are being described in the manual page: There's login_getpwclass(). This function will use the root entry for the root user if it exists, before falling back to default. This is documented as such in the man page, so there are no problems there. In addition, there is login_getuserclass(). According to the PR, this also uses the root entry for the root user, if it exists, before falling back to default if it doesn't. Having now looked at (but not run) the code in src/lib/libutil/login_cap.c, I'm not convinced this last assertion in the PR is actually the case. It looks as if the code to use root instead of default first is in login_getpwclass(), but *not* in login_getuserclass(). So the PR is actually wrong about the text to add. That's fair enough. However, IMHO, the man page could be a bit clearer. Specifically, we have a paragraph that explains how defaults are looked up, and explicitly mentions the default class. We then have four intervening paragraphs, which do not relate to looking up the default entry. Finally, at the end of the fifth paragraph, is the information that login_getpwclass() will use a root entry first, before trying for default if the user being looked up is root. This last piece of information really belongs with the earlier paragraph (although it can be repeated later on). With that in mind, how about this patch (in conjunction with the patch to login.conf in the original PR, which just updates a comment)? --- login_cap.3.org Thu Jul 8 13:15:35 1999 +++ login_cap.3 Thu Jul 8 13:22:00 1999 @@ -147,6 +147,11 @@ with that name returned in the .Ar lc_class field. +In addition, if the referenced user has a UID of 0 (normally, +root, although the user name is not considered) then +.Fn login_getpwclass +will search for a record with an id of root before it searches +for the record with the id of default. .Pp The .Ar lc_cap @@ -231,6 +236,7 @@ .Fn login_getclass restricts loookup only to the system login class database in .Pa /etc/login.conf . +As explained previously, .Fn login_getpwclass only differs from .Fn login_getclass N -- [intentional self-reference] can be easily accommodated using a blessed, non-self-referential dummy head-node whose own object destructor severs the links. -- Tom Christiansen in 37514...@cs.colorado.edu To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-hackers in the body of the message
Re: docs/12377: doc patch for login_cap.
On Tue, Jul 06, 1999 at 08:06:26AM +0200, Sheldon Hearn wrote: On Mon, 05 Jul 1999 23:56:17 +0100, Nik Clayton wrote: I'm unfamiliar with the ins and outs of the login_cap system. Could someone who is versed in it please take a look at this PR (text included) and let me know whether or not the suggested patch is correct. Quite often, we receive requests to improve documentation that are born out of a failure to read that documentation correctly. I think this PR might be one of those cases. Have a look at the login_cap(3) manpage, into which I suspect the submitter may not have dug deeply enough: I have done. As far as I can tell, the submitter is saying "Yes, the information I was looking for was in the manual page, but it (specifically, that the "root" account doesn't use the "default" entry) is buried as a throw away comment at the end of a long paragraph." The patch in the PR just rewords the paragraph slightly to make this a little more obvious for the next person to come along. I've got no objection to the patch itself, as (IMHO) it does make the para read a little more clearly. If no one objects that it's actually changing the intent of the paragraph then I'll commit it soonish. N -- [intentional self-reference] can be easily accommodated using a blessed, non-self-referential dummy head-node whose own object destructor severs the links. -- Tom Christiansen in [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: docs/12377: doc patch for login_cap.
On Tue, Jul 06, 1999 at 08:06:26AM +0200, Sheldon Hearn wrote: On Mon, 05 Jul 1999 23:56:17 +0100, Nik Clayton wrote: I'm unfamiliar with the ins and outs of the login_cap system. Could someone who is versed in it please take a look at this PR (text included) and let me know whether or not the suggested patch is correct. Quite often, we receive requests to improve documentation that are born out of a failure to read that documentation correctly. I think this PR might be one of those cases. Have a look at the login_cap(3) manpage, into which I suspect the submitter may not have dug deeply enough: I have done. As far as I can tell, the submitter is saying Yes, the information I was looking for was in the manual page, but it (specifically, that the root account doesn't use the default entry) is buried as a throw away comment at the end of a long paragraph. The patch in the PR just rewords the paragraph slightly to make this a little more obvious for the next person to come along. I've got no objection to the patch itself, as (IMHO) it does make the para read a little more clearly. If no one objects that it's actually changing the intent of the paragraph then I'll commit it soonish. N -- [intentional self-reference] can be easily accommodated using a blessed, non-self-referential dummy head-node whose own object destructor severs the links. -- Tom Christiansen in 37514...@cs.colorado.edu To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-hackers in the body of the message
Re: docs/12377: doc patch for login_cap.
On Tue, Jul 06, 1999 at 06:54:20PM +0400, Alexander Voropay wrote: AFAIK, most of login_cap functions could be done via PAM subsystem. It's sound very strange to have two different subsystem with too close functions... Based upon several conversations at USENIX, PAM integration is still a work in progress. John Polstra laid out a lot of the groundwork, but there is still a lot of work left to be done. Regards, --Keith Stevenson-- -- Keith Stevenson System Programmer - Data Center Services - University of Louisville [EMAIL PROTECTED] PGP key fingerprint = 4B 29 A8 95 A8 82 EA A2 29 CE 68 DE FC EE B6 A0 To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: docs/12377: doc patch for login_cap.
On Mon, 05 Jul 1999 23:56:17 +0100, Nik Clayton wrote: I'm unfamiliar with the ins and outs of the login_cap system. Could someone who is versed in it please take a look at this PR (text included) and let me know whether or not the suggested patch is correct. Quite often, we receive requests to improve documentation that are born out of a failure to read that documentation correctly. I think this PR might be one of those cases. Have a look at the login_cap(3) manpage, into which I suspect the submitter may not have dug deeply enough: The functions login_getpwclass(), login_getclass() and login_getuserclass() retrieve the applicable login class record for the user's passwd entry or class name by calling login_getclassbyname(). On failure, NULL is returned. The difference between these functions is that login_getuserclass() includes the user's overriding .login_conf that exists in the user's home directory, login_getpwclass,() and login_getclass() restricts loookup only to the system login class database in /etc/login.conf. login_getpwclass() only differs from login_getclass() in that it allows the default class for user 'root' as root if none has been specified in the password database. Otherwise, if the passwd pointer is NULL, or the user record has no login class, then the system default entry is retrieved. Regards, Sheldon. To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-hackers in the body of the message
Re: docs/12377: doc patch for login_cap.
I'm unfamiliar with the ins and outs of the login_cap system. Could someone who is versed in it please take a look at this PR (text included) and let me know whether or not the suggested patch is correct. Quite often, we receive requests to improve documentation that are born out of a failure to read that documentation correctly. AFAIK, most of login_cap functions could be done via PAM subsystem. It's sound very strange to have two different subsystem with too close functions... -- -=AV=- To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-hackers in the body of the message
Re: docs/12377: doc patch for login_cap.
On Tue, Jul 06, 1999 at 06:54:20PM +0400, Alexander Voropay wrote: AFAIK, most of login_cap functions could be done via PAM subsystem. It's sound very strange to have two different subsystem with too close functions... Based upon several conversations at USENIX, PAM integration is still a work in progress. John Polstra laid out a lot of the groundwork, but there is still a lot of work left to be done. Regards, --Keith Stevenson-- -- Keith Stevenson System Programmer - Data Center Services - University of Louisville k.steven...@louisville.edu PGP key fingerprint = 4B 29 A8 95 A8 82 EA A2 29 CE 68 DE FC EE B6 A0 To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-hackers in the body of the message
