Make it Happen
TIRED OF ENDLESSLY POSTING YOUR ONLINE CLASSIFIED AD AND GETTING NO RESULTS? There are over 7000 such sites scattered about the web; and quite frankly, none of them generate enough traffic to be worth your while. Even when someone finds or visits one of these sites, your ad is hopelessly lost in a myriad of similar offerings. Another frustration is search engines. If you are not in the Top 10, forget about high-traffic on your web site. Not everyone can be in the Top 10 and stay there; when there are estimates of four million web pages! How do we know? We know because that's exactly what we used to do. The greatest way of marketing this century is undoubtedly direct e-mail. It's similar to the postman delivering a letter to your mailbox. There is NO stumbling on to it! The ability to promote your product, service, website, or MLM/network marketing opportunity to millions instantly is what advertisers have been dreaming of for over 100 years. We will e-mail your one page promotion to a list of our general addresses. The greatest part is, it's completely affordable. --- NOTICE: Absolutely no pornography, chain letters, get rich quick, pyramid schemes, or any threatening or questionable materials. --- STANDARD PRICING AND PROCEDURES --- EXTRACTING: Our list of general Internet addreses are actually extracted from the most popular web sites on the Internet. The addresses are verified and run through our purification process. The process includes addresses run against our custom remove filter of 2,492 keywords, as well as through our 192MB remove /flamer list. The EDU, ORG, GOV, MIL, and US domains are removed, as well as other domains that asked not to receive e-mail. --- SET-UP FEE: $150.00 This will cover the costs of uploading files, Internet Access (ISP), and software set-up. --- EVALUATION: $350.00 (optional) One of our marketing specialists will evaluate your sales letter, and offer his/her expertise on how to make it the most successful. --- STANDARD PRICING: (Emails Delivered) 1 Million- $800.00 per 2 Million- $700.00 per 3 Million up- $600.00 per --- SPECIAL OFFER! This introductory offer of $475.00 includes: 1. Set-Up Fee 2. Evaluation of Sales Letter 3. 250,000 e-mails delivered --- PAYMENT POLICY All services must be paid in full prior to delivery of advertisement. Under NO CIRCUMSTANCES will any sales or marketing strategies be discussed until payment is received. --- If you are serious about Direct Email Marketing--Fax the following form to (602) 392-8288 -- PLEASE FILL THIS FORM OUT COMPLETELY! Contact Name: _ Business Name: __ Business Type: __ # Years in Business: _ Address: _ City: State: __ Zip: __ Country: ___ Email Address: ___ Phone: __Fax: --- To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Step1, pam_unix srandomdev fix for review
Bug: srandomdev() can't be used in libraries because it touch internal RNG state which may be used by user program which not want true randomness but pseudo one. Fix: srandomdev() removed, random() replaced by arc4random() which initialize itself from true randomness automatically. --- pam_unix.c.old Sat Jan 19 21:29:49 2002 +++ pam_unix.c Sun Jan 20 21:42:47 2002 @@ -502,15 +502,14 @@ syslog(LOG_ERR, cannot set password cipher); login_close(lc); /* Salt suitable for anything */ - srandomdev(); gettimeofday(tv, 0); - to64(salt[0], random(), 3); + to64(salt[0], arc4random(), 3); to64(salt[3], tv.tv_usec, 3); to64(salt[6], tv.tv_sec, 2); - to64(salt[8], random(), 5); - to64(salt[13], random(), 5); - to64(salt[17], random(), 5); - to64(salt[22], random(), 5); + to64(salt[8], arc4random(), 5); + to64(salt[13], arc4random(), 5); + to64(salt[17], arc4random(), 5); + to64(salt[22], arc4random(), 5); salt[27] = '\0'; pwd-pw_passwd = crypt(pass, salt); @@ -596,15 +595,14 @@ syslog(LOG_ERR, cannot set password cipher); login_close(lc); /* Salt suitable for anything */ - srandomdev(); gettimeofday(tv, 0); - to64(salt[0], random(), 3); + to64(salt[0], arc4random(), 3); to64(salt[3], tv.tv_usec, 3); to64(salt[6], tv.tv_sec, 2); - to64(salt[8], random(), 5); - to64(salt[13], random(), 5); - to64(salt[17], random(), 5); - to64(salt[22], random(), 5); + to64(salt[8], arc4random(), 5); + to64(salt[13], arc4random(), 5); + to64(salt[17], arc4random(), 5); + to64(salt[22], arc4random(), 5); salt[27] = '\0'; if (suser_override) -- Andrey A. Chernov http://ache.pp.ru/ To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Step2, pam_unix just expired pass fix for review
Bug:
There is possible when pam_sm_acct_mgmt() called, password is not
expired, but due to some delay between calls (like network delays for NIS
passwords), expired at the moment of pam_sm_authenticate() check.
It may allow user to enter with expired password under some circumstanes
when he is not allowed to do it.
Fix:
Use traditional Unix check (like found in pre-PAM ftpd.c and login.c) for
password expiration at the last moment, i.e. right after checking that it
is valid.
--- pam_unix.c.bak1 Sun Jan 20 21:42:47 2002
+++ pam_unix.c Sun Jan 20 21:58:45 2002
@@ -152,6 +152,8 @@
retval = strcmp(encrypted, pwd-pw_passwd) == 0 ?
PAM_SUCCESS : PAM_AUTH_ERR;
+ if (pwd-pw_expire time(NULL) = pwd-pw_expire)
+ retval = PAM_AUTH_ERR;
}
else {
--
Andrey A. Chernov
http://ache.pp.ru/
To Unsubscribe: send mail to [EMAIL PROTECTED]
with unsubscribe freebsd-current in the body of the message
Diskless Boot Working in -Current ??
I have several kernels built using v4.3 that boot fine over an etherboot/NFS network but a kernel built using GENERIC (with the necesary options added to diskless booting, does not seem to boot), also the option 'MFS' (Memory File System) seems to have been removed from -CURRENT for some reason this is necessary for DISKLESS NFS booting isn't it ??. To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Step3, pam_opie snprintf bloat fix for review
Bug: snprintf is large and slow, increasing program size and slowing it down. Better way is avoid snprintf when it is not neccessary. Fix: Full functionality of snprintf is not needed below, so it is replaced by much faster strlcpy. --- pam_opie.c.bak Sat Jan 19 21:29:49 2002 +++ pam_opie.c Sun Jan 20 22:23:18 2002 @@ -125,7 +125,7 @@ } /* We have to copy the response, because opieverify mucks with it. */ - snprintf(resp, sizeof resp, %s, response); + strlcpy(resp, response, sizeof resp); /* * Opieverify is supposed to return -1 only if an error occurs. -- Andrey A. Chernov http://ache.pp.ru/ To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: Step3, pam_opie snprintf bloat fix for review
Andrey A. Chernov [EMAIL PROTECTED] writes: Bug: snprintf is large and slow, increasing program size and slowing it down. Better way is avoid snprintf when it is not neccessary. Fix: Full functionality of snprintf is not needed below, so it is replaced by much faster strlcpy. Approved (unless Mark has any objections). DES -- Dag-Erling Smorgrav - [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Step4, pam_opie getpwnam check fix for review
Bug:
getpwnum() (or getlogin() in earlier stage) may return NULL under
various complex circumstanes, but following code not expect it and may
cause NULL pointer reference and core dump.
Fix:
Add check for NULL and return PAM_AUTH_ERR
--- pam_opie.c.bak Sun Jan 20 22:23:18 2002
+++ pam_opie.c Sun Jan 20 22:37:08 2002
@@ -89,7 +89,8 @@
user = NULL;
if (pam_test_option(options, PAM_OPT_AUTH_AS_SELF, NULL)) {
- pwd = getpwnam(getlogin());
+ if ((pwd = getpwnam(getlogin())) == NULL)
+ PAM_RETURN(PAM_AUTH_ERR);
user = pwd-pw_name;
}
else {
--
Andrey A. Chernov
http://ache.pp.ru/
To Unsubscribe: send mail to [EMAIL PROTECTED]
with unsubscribe freebsd-current in the body of the message
Re: Step2, pam_unix just expired pass fix for review
Bug:
There is possible when pam_sm_acct_mgmt() called, password is not
expired, but due to some delay between calls (like network delays for NIS
passwords), expired at the moment of pam_sm_authenticate() check.
It is not pam_sm_authenticate()'s job to determine such things as expiry.
This is the business of pam_sm_acct_mgmt().
It may allow user to enter with expired password under some circumstanes
when he is not allowed to do it.
Do you mean that at at the very edge of password expiry, the user may
still be able log in (maybe some seconds later)? If so this is not a
credible threat.
Fix:
Use traditional Unix check (like found in pre-PAM ftpd.c and login.c) for
password expiration at the last moment, i.e. right after checking that it
is valid.
This fix is wrong for pam_sm_authenticate(), but valid for pam_sm_acct_mgmt().
pam_sm_acct_mgmt() already has something functionally equivalent.
M
--- pam_unix.c.bak1 Sun Jan 20 21:42:47 2002
+++ pam_unix.cSun Jan 20 21:58:45 2002
@@ -152,6 +152,8 @@
retval = strcmp(encrypted, pwd-pw_passwd) == 0 ?
PAM_SUCCESS : PAM_AUTH_ERR;
+ if (pwd-pw_expire time(NULL) = pwd-pw_expire)
+ retval = PAM_AUTH_ERR;
}
else {
--
Andrey A. Chernov
http://ache.pp.ru/
--
o Mark Murray
\_ FreeBSD Services Limited
O.\_Warning: this .sig is umop ap!sdn
To Unsubscribe: send mail to [EMAIL PROTECTED]
with unsubscribe freebsd-current in the body of the message
Re: Step2, pam_unix just expired pass fix for review
On Sun, Jan 20, 2002 at 20:41:09 +0100, Dag-Erling Smorgrav wrote: pam_sm_acct_mgmt() is allowed to return PAM_AUTHTOK_EXPIRED (which is a better return value than PAM_AUTH_ERR for this case). Other than that, I have no objections to your patch. This is fix for pam_sm_authenticate(), not for pam_sm_acct_mgmt(). Is pam_sm_authenticate() allowed to return PAM_AUTHTOK_EXPIRED too? I don't find it in allowed return codes list. -- Andrey A. Chernov http://ache.pp.ru/ To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: Step2, pam_unix just expired pass fix for review
On Sun, Jan 20, 2002 at 19:47:55 +, Mark Murray wrote: Do you mean that at at the very edge of password expiry, the user may still be able log in (maybe some seconds later)? If so this is not a credible threat. Yes. Few seconds can be few hours or more in case network is down or something like, this mainly for network passwords like NIS. -- Andrey A. Chernov http://ache.pp.ru/ To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: Step1, pam_unix srandomdev fix for review
Bug: srandomdev() can't be used in libraries because it touch internal RNG state which may be used by user program which not want true randomness but pseudo one. Fix: srandomdev() removed, random() replaced by arc4random() which initialize itself from true randomness automatically. This works, but strikes me as overkill. This is salt, not cryptographic randomness, so 'srandom(junk)' is most likely better as a replacement for srandomdev() (where 'junk' can be time(), pid or anything similar). Salt's purpose is to make pre-computing a dictionary infeasable from the pure space perspective. M --- pam_unix.c.oldSat Jan 19 21:29:49 2002 +++ pam_unix.cSun Jan 20 21:42:47 2002 @@ -502,15 +502,14 @@ syslog(LOG_ERR, cannot set password cipher); login_close(lc); /* Salt suitable for anything */ - srandomdev(); gettimeofday(tv, 0); - to64(salt[0], random(), 3); + to64(salt[0], arc4random(), 3); to64(salt[3], tv.tv_usec, 3); to64(salt[6], tv.tv_sec, 2); - to64(salt[8], random(), 5); - to64(salt[13], random(), 5); - to64(salt[17], random(), 5); - to64(salt[22], random(), 5); + to64(salt[8], arc4random(), 5); + to64(salt[13], arc4random(), 5); + to64(salt[17], arc4random(), 5); + to64(salt[22], arc4random(), 5); salt[27] = '\0'; pwd-pw_passwd = crypt(pass, salt); @@ -596,15 +595,14 @@ syslog(LOG_ERR, cannot set password cipher); login_close(lc); /* Salt suitable for anything */ - srandomdev(); gettimeofday(tv, 0); - to64(salt[0], random(), 3); + to64(salt[0], arc4random(), 3); to64(salt[3], tv.tv_usec, 3); to64(salt[6], tv.tv_sec, 2); - to64(salt[8], random(), 5); - to64(salt[13], random(), 5); - to64(salt[17], random(), 5); - to64(salt[22], random(), 5); + to64(salt[8], arc4random(), 5); + to64(salt[13], arc4random(), 5); + to64(salt[17], arc4random(), 5); + to64(salt[22], arc4random(), 5); salt[27] = '\0'; if (suser_override) -- Andrey A. Chernov http://ache.pp.ru/ -- o Mark Murray \_ FreeBSD Services Limited O.\_Warning: this .sig is umop ap!sdn To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: Step4, pam_opie getpwnam check fix for review
Andrey A. Chernov [EMAIL PROTECTED] writes: Bug: getpwnum() (or getlogin() in earlier stage) may return NULL under various complex circumstanes, but following code not expect it and may cause NULL pointer reference and core dump. Fix: Add check for NULL and return PAM_AUTH_ERR Approved (unless Mark objects). Strictly speaking, I think getlogin() should be replaced with the result of pam_get_item(PAM_RUSER), but that's separate issue. DES -- Dag-Erling Smorgrav - [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: Step2, pam_unix just expired pass fix for review
Mark Murray [EMAIL PROTECTED] writes: Bug: There is possible when pam_sm_acct_mgmt() called, password is not expired, but due to some delay between calls (like network delays for NIS passwords), expired at the moment of pam_sm_authenticate() check. It is not pam_sm_authenticate()'s job to determine such things as expiry. This is the business of pam_sm_acct_mgmt(). Oww, I thought this patch *was* to pam_sm_acct_mgmt(), but I just realized it's not. You're right, it's inappropriate for pam_sm_authenticate(). DES -- Dag-Erling Smorgrav - [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: Step3, pam_opie snprintf bloat fix for review
Bug: snprintf is large and slow, increasing program size and slowing it down. Better way is avoid snprintf when it is not neccessary. Fix: Full functionality of snprintf is not needed below, so it is replaced by much faster strlcpy. This is fine! Style - please make it 'sizeof(foo)', not 'sizeof foo'. M --- pam_opie.c.bakSat Jan 19 21:29:49 2002 +++ pam_opie.cSun Jan 20 22:23:18 2002 @@ -125,7 +125,7 @@ } /* We have to copy the response, because opieverify mucks with it. */ - snprintf(resp, sizeof resp, %s, response); + strlcpy(resp, response, sizeof resp); /* * Opieverify is supposed to return -1 only if an error occurs. -- Andrey A. Chernov http://ache.pp.ru/ To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message -- o Mark Murray \_ FreeBSD Services Limited O.\_Warning: this .sig is umop ap!sdn To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: Step1, pam_unix srandomdev fix for review
On Sun, Jan 20, 2002 at 19:55:31 +, Mark Murray wrote: This works, but strikes me as overkill. This is salt, not cryptographic randomness, so 'srandom(junk)' is most likely better as a replacement for srandomdev() (where 'junk' can be time(), pid or anything similar). You can't call srandom() from the libraries for the same purposes as srandomdev(), i.e. it damages user application current RNG state in the same way. I mean this: 1) User call srandom(3) 2) Library calls srandomdev() or srandom(123) Second step is effectively damages srandom(3) RNG state. -- Andrey A. Chernov http://ache.pp.ru/ To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: Step2, pam_unix just expired pass fix for review
Andrey A. Chernov [EMAIL PROTECTED] writes: On Sun, Jan 20, 2002 at 20:41:09 +0100, Dag-Erling Smorgrav wrote: pam_sm_acct_mgmt() is allowed to return PAM_AUTHTOK_EXPIRED (which is a better return value than PAM_AUTH_ERR for this case). Other than that, I have no objections to your patch. This is fix for pam_sm_authenticate(), not for pam_sm_acct_mgmt(). Is pam_sm_authenticate() allowed to return PAM_AUTHTOK_EXPIRED too? I don't find it in allowed return codes list. I misread your mail. Pam_sm_authenticate() is not supposed to care that the password is expired. If it did, it users with expired passwords would be effectively locked out; they're supposed to get a chance to change their password. The application is supposed to call pam_chauthtok() if pam_acct_mgmt() returns PAM_AUTHTOK_EXPIRED; see the sample application in DCE RFC 86.0. DES -- Dag-Erling Smorgrav - [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: Step2, pam_unix just expired pass fix for review
On Sun, Jan 20, 2002 at 19:47:55 +, Mark Murray wrote: Do you mean that at at the very edge of password expiry, the user may still be able log in (maybe some seconds later)? If so this is not a credible threat. Yes. Few seconds can be few hours or more in case network is down or something like, this mainly for network passwords like NIS. This is still not something that is pam_authenticate()'s business. If you believe that this is a problem, then the order and time in which these are done inside pam needs to be addressed, not by kluging pam modules. Perhaps the PAM-using applications need to be looked at as well to make sure they don't do anything silly. pam_authenticate() answers the question does the user have the correct credentials?. pam_acct_mgmt() answers the question OK - they are who they say they are. Are they allowed in _now_?. M -- o Mark Murray \_ FreeBSD Services Limited O.\_Warning: this .sig is umop ap!sdn To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: Step2, pam_unix just expired pass fix for review
Mark Murray [EMAIL PROTECTED] writes: On Sun, Jan 20, 2002 at 19:47:55 +, Mark Murray wrote: Do you mean that at at the very edge of password expiry, the user may still be able log in (maybe some seconds later)? If so this is not a credible threat. Yes. Few seconds can be few hours or more in case network is down or something like, this mainly for network passwords like NIS. This is still not something that is pam_authenticate()'s business. [...] I think this is all a misunderstanding (I misunderstood it too at first). There is no race. First, pam_authenticate() returns PAM_SUCCESS if the password was correct, regardless of whether it's expired. Next, pam_acct_mgmt() returns PAM_AUTHTOK_EXPIRED if the password has expired when it is called. Everything works as expected even if the password expires between the two calls. DES -- Dag-Erling Smorgrav - [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: Step2, pam_unix just expired pass fix for review
On Sun, Jan 20, 2002 at 20:06:32 +, Mark Murray wrote: pam_authenticate() answers the question does the user have the correct credentials?. pam_acct_mgmt() answers the question OK - they are who they say they are. Are they allowed in _now_?. Well, I tend to agree, Step2 is withdrawed. -- Andrey A. Chernov http://ache.pp.ru/ To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: Step1, pam_unix srandomdev fix for review
On Sun, Jan 20, 2002 at 19:55:31 +, Mark Murray wrote: This works, but strikes me as overkill. This is salt, not cryptographic randomness, so 'srandom(junk)' is most likely better as a replacement for srandomdev() (where 'junk' can be time(), pid or anything similar). You can't call srandom() from the libraries for the same purposes as srandomdev(), i.e. it damages user application current RNG state in the same way. Hmm. OK. Do you understand, though, why the salt does not need cryptographic randomness? Another patch of yours replaced sprintf with a faster strlcpy, but this uses the _much_ slower arc4random() which is not necessary IMO. How about just using pid's or something? The original crypt(3) salt quantised the time-of-day into 4096 pieces for the salt - how about doing something like that? UUEncode time()|pid()|getuid() might work just fine. I mean this: 1) User call srandom(3) 2) Library calls srandomdev() or srandom(123) Second step is effectively damages srandom(3) RNG state. -- Andrey A. Chernov http://ache.pp.ru/ -- o Mark Murray \_ FreeBSD Services Limited O.\_Warning: this .sig is umop ap!sdn To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: Step1, pam_unix srandomdev fix for review
On Sun, Jan 20, 2002 at 20:34:35 +, Mark Murray wrote: The original crypt(3) salt quantised the time-of-day into 4096 pieces for the salt - how about doing something like that? UUEncode time()|pid()|getuid() might work just fine. I agree. But I don't plan to improve PAM in this my fix, I just want to unbreak application first. Someone else can do what you suggest afterwards. In which case, please don't make your commit. I understand the problem, and disagree with the fix, so I'll fix it in a different way myself. Ok, but please don't forget it. -- Andrey A. Chernov http://ache.pp.ru/ To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: Step1, pam_unix srandomdev fix for review
Andrey A. Chernov wrote: On Sun, Jan 20, 2002 at 19:55:31 +, Mark Murray wrote: This works, but strikes me as overkill. This is salt, not cryptographic randomness, so 'srandom(junk)' is most likely better as a replacement for srandomdev() (where 'junk' can be time(), pid or anything similar). You can't call srandom() from the libraries for the same purposes as srandomdev(), i.e. it damages user application current RNG state in the same way. I mean this: 1) User call srandom(3) 2) Library calls srandomdev() or srandom(123) Second step is effectively damages srandom(3) RNG state. Since the library is a totally encapsulated usage, it makes sense for it to save and restore state aroun its use of the functions, which would effectively allow concurrent use of the generator with other code that uses it. Other code that cares about the state should do the same. -- Terry To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: Step1, pam_unix srandomdev fix for review
Second step is effectively damages srandom(3) RNG state. Since the library is a totally encapsulated usage, it makes sense for it to save and restore state aroun its use of the functions, which would effectively allow concurrent use of the generator with other code that uses it. Other code that cares about the state should do the same. True but not trivial. I'd be happy to commit working patches :-) M -- o Mark Murray \_ FreeBSD Services Limited O.\_Warning: this .sig is umop ap!sdn To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Step5, pam_opie OPIE auth fix for review
Bug:
pam_opie module _always_ allows Unix (plaintext) password, even in the
cases which are disabled by OPIE auth procedure.
Description:
How non-PAM standalone OPIE works:
1) If OPIE user exists, its remote host checked against /etc/opieaccess
via opieaccessfile()
2) If remote host is found there, user home dir checked for ~/.opiealways
file via opiealways()
3) If no such file, it is assumed than OPIE user is allowed to
authenticate with plaintext (Unix) password additionly to OPIE exchange.
In all other cases OPIE user is not allowed to authenticate with plaintext
(Unix) password.
How PAM OPIE works:
OPIE user can _always_ authenticate with plaintext (Unix) password which
is is security lowering and violates OPIE way of things.
Fix:
It can't be fixed in current 2-state pam_opie return codes model, we need
3 codes:
1) For OPIE exchange success
2) For OPIE exchange failure, but Unix (plaintext) passwords allowed
3) For OPIE exchange failure, but Unix (plaintext) passwords disabled
1) and 2) works exact as in old 2-state model, so 1) is PAM_SUCCESS and 2)
is PAM_AUTH_ERR.
I choose PAM_CRED_INSUFFICIENT for case 3) which means that pam_opie
module deside that all additionally possible auth will be insufficient and
returns immediately from modules chain with this code.
--- pam_opie.c.old Sun Jan 20 23:56:47 2002
+++ pam_opie.c Mon Jan 21 00:24:51 2002
@@ -66,13 +66,14 @@
struct opie opie;
struct options options;
struct passwd *pwd;
- int retval, i;
+ int retval, i, pwok;
char *(promptstr[]) = { %s\nPassword: , %s\nPassword [echo on]: };
char challenge[OPIE_CHALLENGE_MAX];
char prompt[OPIE_CHALLENGE_MAX+22];
char resp[OPIE_SECRET_MAX];
const char *user;
const char *response;
+ const char *rhost;
pam_std_option(options, other_options, argc, argv);
@@ -97,6 +98,8 @@
retval = pam_get_user(pamh, (const char **)user, NULL);
if (retval != PAM_SUCCESS)
PAM_RETURN(retval);
+ if ((pwd = getpwnam(user)) == NULL)
+ PAM_RETURN(PAM_AUTH_ERR);
}
PAM_LOG(Got user: %s, user);
@@ -107,7 +110,14 @@
*/
opiedisableaeh();
- opiechallenge(opie, (char *)user, challenge);
+ if (opiechallenge(opie, (char *)user, challenge) == 0) {
+ rhost = NULL;
+ (void) pam_get_item(pamh, PAM_RHOST, (const void **)rhost);
+ pwok = (rhost != NULL) (*rhost != '\0')
+ opieaccessfile((char *)rhost)
+ opiealways(pwd-pw_dir);
+ } else
+ pwok = 1;
for (i = 0; i 2; i++) {
snprintf(prompt, sizeof prompt, promptstr[i], challenge);
retval = pam_get_pass(pamh, response, prompt, options);
@@ -134,7 +144,10 @@
* it expects. Thus we can't log an error and can only check for
* success or lack thereof.
*/
- retval = opieverify(opie, resp) == 0 ? PAM_SUCCESS : PAM_AUTH_ERR;
+ if (opieverify(opie, resp) != 0)
+ retval = pwok ? PAM_AUTH_ERR : PAM_CRED_INSUFFICIENT;
+ else
+ retval = PAM_SUCCESS;
PAM_RETURN(retval);
}
--- ftpd.c.bak Sat Jan 19 21:29:50 2002
+++ ftpd.c Mon Jan 21 00:30:03 2002
@@ -1190,6 +1190,7 @@
break;
case PAM_AUTH_ERR:
+ case PAM_CRED_INSUFFICIENT:
case PAM_USER_UNKNOWN:
case PAM_MAXTRIES:
rval = 1;
--- login.c.bak Sat Jan 19 21:05:16 2002
+++ login.c Mon Jan 21 00:31:45 2002
@@ -802,6 +802,7 @@
break;
case PAM_AUTH_ERR:
+ case PAM_CRED_INSUFFICIENT:
case PAM_USER_UNKNOWN:
case PAM_MAXTRIES:
rval = 1;
--- su.bak Sat Jan 19 21:29:49 2002
+++ su Mon Jan 21 00:39:04 2002
@@ -9,7 +9,7 @@
auth requisite pam_wheel.sono_warn auth_as_self noroot_ok
#auth sufficient pam_kerberosIV.so no_warn
#auth sufficient pam_krb5.so no_warn try_first_pass auth_as_self
-#auth requiredpam_opie.so no_warn
+#auth [defalt=ignore success=done cred_insufficient=die] pam_opie.so no_warn
#auth requiredpam_ssh.so no_warn try_first_pass
auth requiredpam_unix.so no_warn try_first_pass nullok
#auth sufficient pam_rootok.so no_warn
--- login.bak Sat Jan 19 21:29:49 2002
+++ login Mon Jan 21 00:39:04 2002
@@ -6,7 +6,7 @@
# auth
auth requiredpam_nologin.so no_warn
-#auth sufficient pam_opie.so no_warn
+#auth [defalt=ignore success=done cred_insufficient=die] pam_opie.so no_warn
#auth sufficient pam_kerberosIV.so no_warn try_first_pass
#auth sufficient pam_krb5.so no_warn try_first_pass
#auth required
Re: Step5, pam_opie OPIE auth fix for review
Bug:
pam_opie module _always_ allows Unix (plaintext) password, even in the
cases which are disabled by OPIE auth procedure.
I agree that this is a bug.
Description:
How non-PAM standalone OPIE works:
1) If OPIE user exists, its remote host checked against /etc/opieaccess
via opieaccessfile()
2) If remote host is found there, user home dir checked for ~/.opiealways
file via opiealways()
3) If no such file, it is assumed than OPIE user is allowed to
authenticate with plaintext (Unix) password additionly to OPIE exchange.
The PAM OPIE may only do OPIE authentication. It is entirely up to the
PAM stack to decide what the login policy is.
(Well, the PAM stack as specified by the pam configs in /etc/pam*)
In all other cases OPIE user is not allowed to authenticate with plaintext
(Unix) password.
How PAM OPIE works:
OPIE user can _always_ authenticate with plaintext (Unix) password which
is is security lowering and violates OPIE way of things.
Oops. Yes. That is not good.
Fix:
It can't be fixed in current 2-state pam_opie return codes model, we need
3 codes:
1) For OPIE exchange success
2) For OPIE exchange failure, but Unix (plaintext) passwords allowed
3) For OPIE exchange failure, but Unix (plaintext) passwords disabled
Nope. I disagree.
1) Success.
2) Failure.
3) Failure.
1) and 2) works exact as in old 2-state model, so 1) is PAM_SUCCESS and 2)
is PAM_AUTH_ERR.
2) and 3) are _both_ PAM_AUTH_ERR.
However - the module may pass on the authentication token (the password)
and any following modules are allowed to use this if they find it.
(look at the try_first_pass and use_fist_pass options).
I choose PAM_CRED_INSUFFICIENT for case 3) which means that pam_opie
module deside that all additionally possible auth will be insufficient and
returns immediately from modules chain with this code.
No. This is messing with the PAM stack in a weird way. I disagree
with this method.
--- pam_opie.c.oldSun Jan 20 23:56:47 2002
+++ pam_opie.cMon Jan 21 00:24:51 2002
@@ -66,13 +66,14 @@
struct opie opie;
struct options options;
struct passwd *pwd;
- int retval, i;
+ int retval, i, pwok;
char *(promptstr[]) = { %s\nPassword: , %s\nPassword [echo on]: };
char challenge[OPIE_CHALLENGE_MAX];
char prompt[OPIE_CHALLENGE_MAX+22];
char resp[OPIE_SECRET_MAX];
const char *user;
const char *response;
+ const char *rhost;
pam_std_option(options, other_options, argc, argv);
@@ -97,6 +98,8 @@
retval = pam_get_user(pamh, (const char **)user, NULL);
if (retval != PAM_SUCCESS)
PAM_RETURN(retval);
+ if ((pwd = getpwnam(user)) == NULL)
+ PAM_RETURN(PAM_AUTH_ERR);
}
PAM_LOG(Got user: %s, user);
@@ -107,7 +110,14 @@
*/
opiedisableaeh();
- opiechallenge(opie, (char *)user, challenge);
+ if (opiechallenge(opie, (char *)user, challenge) == 0) {
+ rhost = NULL;
+ (void) pam_get_item(pamh, PAM_RHOST, (const void **)rhost);
+ pwok = (rhost != NULL) (*rhost != '\0')
+opieaccessfile((char *)rhost)
+opiealways(pwd-pw_dir);
+ } else
+ pwok = 1;
for (i = 0; i 2; i++) {
snprintf(prompt, sizeof prompt, promptstr[i], challenge);
retval = pam_get_pass(pamh, response, prompt, options);
@@ -134,7 +144,10 @@
* it expects. Thus we can't log an error and can only check for
* success or lack thereof.
*/
- retval = opieverify(opie, resp) == 0 ? PAM_SUCCESS : PAM_AUTH_ERR;
+ if (opieverify(opie, resp) != 0)
+ retval = pwok ? PAM_AUTH_ERR : PAM_CRED_INSUFFICIENT;
+ else
+ retval = PAM_SUCCESS;
PAM_RETURN(retval);
}
--- ftpd.c.bakSat Jan 19 21:29:50 2002
+++ ftpd.cMon Jan 21 00:30:03 2002
@@ -1190,6 +1190,7 @@
break;
case PAM_AUTH_ERR:
+ case PAM_CRED_INSUFFICIENT:
case PAM_USER_UNKNOWN:
case PAM_MAXTRIES:
rval = 1;
--- login.c.bak Sat Jan 19 21:05:16 2002
+++ login.c Mon Jan 21 00:31:45 2002
@@ -802,6 +802,7 @@
break;
case PAM_AUTH_ERR:
+ case PAM_CRED_INSUFFICIENT:
case PAM_USER_UNKNOWN:
case PAM_MAXTRIES:
rval = 1;
--- su.bakSat Jan 19 21:29:49 2002
+++ suMon Jan 21 00:39:04 2002
@@ -9,7 +9,7 @@
auth requisite pam_wheel.sono_warn auth_as_self noroot_ok
#authsufficient pam_kerberosIV.so no_warn
#authsufficient pam_krb5.so no_warn try_first_pass
auth_as_self
-#authrequiredpam_opie.so no_warn
+#auth [defalt=ignore success=done cred_insufficient=die] pam_opie.so no_warn
#auth
Current Etherboot
etherboot runs fine on Current, all that is required if to have the 'device.hints' statically compiled into the kernel you are trying to boot: #To statically compile in device wiring instead of /boot/device.hints hints NETBOOT.hints #Default places to look for devices. bit strange that the 'regulars' on the list didn't seem to know about this ... Glenn Gombert [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: Step5, pam_opie OPIE auth fix for review
On Sun, Jan 20, 2002 at 23:14:13 +, Mark Murray wrote: The PAM OPIE may only do OPIE authentication. It is entirely up to the PAM stack to decide what the login policy is. (Well, the PAM stack as specified by the pam configs in /etc/pam*) Yes. And to allow PAM stack to make right decision, pam_opie pass special information to PAM stack. Look at the patch, pam_opie not breaks from the stack by yourself, it is /etc/pam* do that using information from pam_opie. However - the module may pass on the authentication token (the password) and any following modules are allowed to use this if they find it. (look at the try_first_pass and use_fist_pass options). I was thinking about that way but not find a good solution. That way workatround is: 1) In the failure case when Unix (plaintext) passwords are disabled pam_opie can pass specially-generated incorrect password down to pam_unix. 2) pam_unix option must be changed from try_first_pass to use_first_pass, because it asks again for password if try_first_pass active, i.e. allows user to enter Unix (plaintext) password again. So we have the same bug, but shifted to one prompt step. I have doubts about 1): what specially-generated incorrect password can be? It seems that any combination is legal and MAY be equal to real password. -- Andrey A. Chernov http://ache.pp.ru/ To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: Step5, pam_opie OPIE auth fix for review
On Sun, Jan 20, 2002 at 23:14:13 +, Mark Murray wrote: The PAM OPIE may only do OPIE authentication. It is entirely up to the PAM stack to decide what the login policy is. (Well, the PAM stack as specified by the pam configs in /etc/pam*) Yes. And to allow PAM stack to make right decision, pam_opie pass special information to PAM stack. Look at the patch, pam_opie not breaks from the stack by yourself, it is /etc/pam* do that using information from pam_opie. Sure - but you are making specialised use of the return value that assumes that pam_opie will be followed by pam_unix. This violates the PAM spec. However - the module may pass on the authentication token (the password) and any following modules are allowed to use this if they find it. (look at the try_first_pass and use_fist_pass options). I was thinking about that way but not find a good solution. That way workatround is: 1) In the failure case when Unix (plaintext) passwords are disabled pam_opie can pass specially-generated incorrect password down to pam_unix. 2) pam_unix option must be changed from try_first_pass to use_first_pass, because it asks again for password if try_first_pass active, i.e. allows user to enter Unix (plaintext) password again. So we have the same bug, but shifted to one prompt step. You may be able to do something with options. Example: if the sysadmin allows a password to be passed down the stack, otherwise pass a dummy. (like ftpdauthrequiredpam_opie.so keep_password or similar) I have doubts about 1): what specially-generated incorrect password can be? It seems that any combination is legal and MAY be equal to real password. Nope. kill the password if it is not allowed. Pass a NULL. M -- o Mark Murray \_ FreeBSD Services Limited O.\_Warning: this .sig is umop ap!sdn To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: Step5, pam_opie OPIE auth fix for review
Andrey A. Chernov [EMAIL PROTECTED] writes: Yes. And to allow PAM stack to make right decision, pam_opie pass special information to PAM stack. Look at the patch, pam_opie not breaks from the stack by yourself, it is /etc/pam* do that using information from pam_opie. What I can't understand is why OPIE is making that decision in the first place. The only answer I can think of is that it was written before the advent of PAM, and tries to be a poor man's PAM. That is not its place. In any case, if I understand what you're trying to do, it can be done by returning PAM_SUCCESS if OPIE authentication succeeded, PAM_IGNORE if it failed but Unix authentication is still allowed, and PAM_AUTH_ERR if OPIE failed and Unix authentication is *not* allowed. In that case, if you mark pam_opie sufficient, pam_unix will run only if OPIE authentication failed but allowed Unix authentication to proceed. DES -- Dag-Erling Smorgrav - [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: Step5, pam_opie OPIE auth fix for review
On Sun, Jan 20, 2002 at 23:44:44 +, Mark Murray wrote: Yes. And to allow PAM stack to make right decision, pam_opie pass special information to PAM stack. Look at the patch, pam_opie not breaks from the stack by yourself, it is /etc/pam* do that using information from pam_opie. Sure - but you are making specialised use of the return value that assumes that pam_opie will be followed by pam_unix. This violates the PAM spec. The alternative (yet one) way can be adding Unix (plaintext) password checking code directly to pam_opie. It makes pam_opie fully independent of other modules and specific position in the /etc/pam.d/* config files and allows us to not touch them. If you agree with that way, I'll come with the patch. About other points stated in your message, my answer depends on what you deside for above, because it is unneded to discuss them, if you agree to make pam_opie self-containing. -- Andrey A. Chernov http://ache.pp.ru/ To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: Step5, pam_opie OPIE auth fix for review
Dag-Erling Smorgrav [EMAIL PROTECTED] writes: In any case, if I understand what you're trying to do, it can be done by returning PAM_SUCCESS if OPIE authentication succeeded, PAM_IGNORE if it failed but Unix authentication is still allowed, and PAM_AUTH_ERR if OPIE failed and Unix authentication is *not* allowed. In that case, if you mark pam_opie sufficient, pam_unix will run only if OPIE authentication failed but allowed Unix authentication to proceed. Hmm, actually, that won't do. I need to think this over some more. DES -- Dag-Erling Smorgrav - [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: Step5, pam_opie OPIE auth fix for review
On Sun, Jan 20, 2002 at 23:44:44 +, Mark Murray wrote: Yes. And to allow PAM stack to make right decision, pam_opie pass special information to PAM stack. Look at the patch, pam_opie not breaks from the stack by yourself, it is /etc/pam* do that using information from pam_opie. Sure - but you are making specialised use of the return value that assumes that pam_opie will be followed by pam_unix. This violates the PAM spec. The alternative (yet one) way can be adding Unix (plaintext) password checking code directly to pam_opie. It makes pam_opie fully independent of other modules and specific position in the /etc/pam.d/* config files and allows us to not touch them. If you agree with that way, I'll come with the patch. No. I completely disagree with that method. that is pam_unix's job. DES's PAM_IGNORE suggestion has a lot of merit. About other points stated in your message, my answer depends on what you deside for above, because it is unneded to discuss them, if you agree to make pam_opie self-containing. It must be self-contained, and it must not do stuff that is the job of other modules. Unix password checking is not pam_opie's job. M -- o Mark Murray \_ FreeBSD Services Limited O.\_Warning: this .sig is umop ap!sdn To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: Step5, pam_opie OPIE auth fix for review
Dag-Erling Smorgrav [EMAIL PROTECTED] writes: In any case, if I understand what you're trying to do, it can be done by returning PAM_SUCCESS if OPIE authentication succeeded, PAM_IGNORE if it failed but Unix authentication is still allowed, and PAM_AUTH_ERR if OPIE failed and Unix authentication is *not* allowed. In that case, if you mark pam_opie sufficient, pam_unix will run only if OPIE authentication failed but allowed Unix authentication to proceed. Hmm, actually, that won't do. I need to think this over some more. The usual route is YES or NO, with IGNORE reserved for modules which have no authentication (like say, pam_motd, which prints /etc/motd during the pam_session_open() phase). IGNORE may have other uses, but I can't remember them offhand. M -- o Mark Murray \_ FreeBSD Services Limited O.\_Warning: this .sig is umop ap!sdn To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: Step5, pam_opie OPIE auth fix for review
Andrey A. Chernov [EMAIL PROTECTED] writes: The basic OPIE/S-KEY idea under that was that normally only one-time password is allowed, i.e. user is not allowed to type plaintext passwords at all because connection treated as totally insecured one. But for very special cases configured by sysadmin, like working in the same machine or trusted subnet, OPIE/S-KEY additionally allows plaintext password too, depending on its own configuration. That's what PAM is for. If fixed (not necessary plaintext!) passwords are allowed, the admin will mark pam_opie as sufficient and place pam_unix below it; if they're not, he'll just remove pam_unix. The current system, BTW, leaves the policy in the hands of the user, as she can create or remove ~/.opie_always at will. A security policy which is based on letting the user decide what is sufficient authentication and what is not is not a proper security policy. In any case, if I understand what you're trying to do, it can be done by [...] It sounds good, I'll run a test case and inform you about results. Actually, that idea won't work, because PAM will ignore PAM_AUTH_ERR from a sufficient module. A requisite helper module, placed after pam_opie, which fails if ~/.opie_always exists would do the trick, if one really wanted this. DES -- Dag-Erling Smorgrav - [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: Step5, pam_opie OPIE auth fix for review
On Mon, Jan 21, 2002 at 00:09:21 +, Mark Murray wrote: Dag-Erling Smorgrav [EMAIL PROTECTED] writes: In any case, if I understand what you're trying to do, it can be done by returning PAM_SUCCESS if OPIE authentication succeeded, PAM_IGNORE if it failed but Unix authentication is still allowed, and PAM_AUTH_ERR if OPIE failed and Unix authentication is *not* allowed. In that case, if you mark pam_opie sufficient, pam_unix will run only if OPIE authentication failed but allowed Unix authentication to proceed. Hmm, actually, that won't do. I need to think this over some more. The usual route is YES or NO, with IGNORE reserved for modules which have no authentication (like say, pam_motd, which prints /etc/motd during the pam_session_open() phase). IGNORE may have other uses, but I can't remember them offhand. sufficient will not works due to IGNORE assigned to AUTH_ERR reaction. [default=ignore success=done auth_err=die] works. Do you agree with this variant? -- Andrey A. Chernov http://ache.pp.ru/ To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
For Review: sendmail 8.12.2 import into -CURRENT
I am seeking volunteers to review and test the infrastructure changes needed to import sendmail 8.12.2 into FreeBSD (-CURRENT). If you are interested in helping, please visit: http://people.freebsd.org/~gshapiro/CURRENT-8.12.2 and following the instructions there. Please report any successes or failures to me directly. (-STABLE users -- I'll be posting a similar message to freebsd-stable once I've collected enough feedback here and 8.12.2 has been imported into the HEAD.) To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: Step5, pam_opie OPIE auth fix for review
On Mon, Jan 21, 2002 at 01:17:44 +0100, Dag-Erling Smorgrav wrote: That's what PAM is for. If fixed (not necessary plaintext!) passwords are allowed, the admin will mark pam_opie as sufficient and place pam_unix below it; if they're not, he'll just remove pam_unix. It not allows flexible configuration because it is not depends on remote host for example. I.e. for some host pam_unix can be chained, but for some another - not. The current system, BTW, leaves the policy in the hands of the user, as she can create or remove ~/.opie_always at will. A security policy which is based on letting the user decide what is sufficient authentication and what is not is not a proper security policy. No, by creating ~/.opiealways user can only _increase_ its own security level additionly to pre-setted by sysadmin for him, and can't _decrease_ it. Actually, that idea won't work, because PAM will ignore PAM_AUTH_ERR from a sufficient module. A requisite helper module, placed after pam_opie, which fails if ~/.opie_always exists would do the trick, if one really wanted this. ~/.opiealways checked only if opieaccess() found remote host in the /etc/opieaccess table. Yes, this check can be done as separate PAM module, but why two modules in the same area instead of one? -- Andrey A. Chernov http://ache.pp.ru/ To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: Step5, pam_opie OPIE auth fix for review
sufficient will not works due to IGNORE assigned to AUTH_ERR reaction. [default=ignore success=done auth_err=die] works. Do you agree with this variant? Eeew. It may work, but it is really a last-ditch sort of thing. I much prefer an option that specifies the behaviour. M -- o Mark Murray \_ FreeBSD Services Limited O.\_Warning: this .sig is umop ap!sdn To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: profiled kernel build fails was Re: -CURRENT AIO bug
Should I file a PR to track this or is that overkill?
-Kip
--- Bruce Evans [EMAIL PROTECTED] wrote:
On Sat, 19 Jan 2002, k Macy wrote:
Thanks for working on this. I was going to try
running
a profiled kernel on -CURRENT and -STABLE to see
what
the difference was in time distribution. On
-STABLE
it built without a hitch. However, on -CURRENT I
got
the following even after doing a make clean:
../../../libkern/mcount.c: In function `mcount':
../../../libkern/mcount.c:91: `mcount_lock'
undeclared
(first use in this function)
The mcount_lock stuff apparently never even
compiled. It is only used
for the !GUPROF SMP case, but it cannot work in
that case since
mcount_lock is not declared. Unfortunately, LINT
only tests the GUPROF
case, which compiles but is even more broken at
runtime in the SMP
case. GUPROF worse fine in the !SMP case and should
be non-optional
(it gives about 10 times as much resolution as
PROF on current
machines, instead of only 1000 times as much as on
486's when it was
written).
This fix has not been tested. It has some chance of
working, because
RELENG_4 uses similar code. However, it is
certainly broken if the
atomic functions that it calls are not inlined (then
the functions will
call MCOUNT_ENTER() on entry). I think this only
happens if mcount.c
is compiled with -O0. This bug is missing in
RELENG_4 too.
%%%
Index: profile.h
===
RCS file:
/home/ncvs/src/sys/i386/include/profile.h,v
retrieving revision 1.25
diff -u -2 -r1.25 profile.h
--- profile.h 30 Oct 2001 15:04:57 - 1.25
+++ profile.h 20 Jan 2002 06:05:24 -
@@ -65,4 +65,5 @@
#define MCOUNT_DECL(s) u_long s;
#ifdef SMP
+extern int mcount_lock;
#define MCOUNT_ENTER(s) { s = read_eflags();
disable_intr(); \
while (!atomic_cmpset_acq_int(mcount_lock,
0, 1)) \
%%%
Bruce
__
Do You Yahoo!?
Send FREE video emails in Yahoo! Mail!
http://promo.yahoo.com/videomail/
To Unsubscribe: send mail to [EMAIL PROTECTED]
with unsubscribe freebsd-current in the body of the message
Re: Step5, pam_opie OPIE auth fix for review
Andrey A. Chernov [EMAIL PROTECTED] writes: [default=ignore success=done auth_err=die] works. Do you agree with this variant? No. That's a Linuxism. DES -- Dag-Erling Smorgrav - [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: Step5, pam_opie OPIE auth fix for review
On Mon, Jan 21, 2002 at 00:29:29 +, Mark Murray wrote: sufficient will not works due to IGNORE assigned to AUTH_ERR reaction. [default=ignore success=done auth_err=die] works. Do you agree with this variant? Eeew. It may work, but it is really a last-ditch sort of thing. What you dislike in that way? This method fully described in pam(8). I see no differences using short forms like sufficient or its full long analog like [default=ignore sucess=done new_authtok_reqd=done] short forms are only aliases. I much prefer an option that specifies the behaviour. I not understand enough what kind of option you mean exactly, where it whould be and how act exactly. -- Andrey A. Chernov http://ache.pp.ru/ To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: Step5, pam_opie OPIE auth fix for review
On Mon, Jan 21, 2002 at 01:34:02 +0100, Dag-Erling Smorgrav wrote: Andrey A. Chernov [EMAIL PROTECTED] writes: [default=ignore success=done auth_err=die] works. Do you agree with this variant? No. That's a Linuxism. What do you mean, exactly? Long forms are well described in pam(8) and short forms are only aliases to them. -- Andrey A. Chernov http://ache.pp.ru/ To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: Step5, pam_opie OPIE auth fix for review
Andrey A. Chernov [EMAIL PROTECTED] writes: On Mon, Jan 21, 2002 at 01:17:44 +0100, Dag-Erling Smorgrav wrote: The current system, BTW, leaves the policy in the hands of the user, as she can create or remove ~/.opie_always at will. A security policy which is based on letting the user decide what is sufficient authentication and what is not is not a proper security policy. No, by creating ~/.opiealways user can only _increase_ its own security level additionly to pre-setted by sysadmin for him, and can't _decrease_ it. The admin can't enforce always OPIE for a user, because the user can always delete his ~/.opiealways. Actually, that idea won't work, because PAM will ignore PAM_AUTH_ERR from a sufficient module. A requisite helper module, placed after pam_opie, which fails if ~/.opie_always exists would do the trick, if one really wanted this. ~/.opiealways checked only if opieaccess() found remote host in the /etc/opieaccess table. Oh. I misunderstood the role of /etc/opieaccess in this. This only strengthens my opinion that this check should be in a separate module. How about I write a pam_opieaccess(8) module and you tell me what you think of it? It's really the cleanest solution from PAM's point of view. Yes, this check can be done as separate PAM module, but why two modules in the same area instead of one? Because they're different mechanisms that check different things, and their success or failure have different meanings. DES -- Dag-Erling Smorgrav - [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: Step5, pam_opie OPIE auth fix for review
Andrey A. Chernov [EMAIL PROTECTED] writes: What you dislike in that way? This method fully described in pam(8). The fact that it is described in pam(8) does not mean we like it. We also have a man page for gets(3), but you know what BDE will say if you try to use it. I see no differences using short forms like sufficient or its full long analog like [default=ignore sucess=done new_authtok_reqd=done] short forms are only aliases. No. The [...] form is a Linux-PAM invention, and is tightly linked to Linux-PAM implementation details. It does not exist in other PAM implementations. I aim to move *away* from dependence on Linux-PAM, not *towards* it. DES -- Dag-Erling Smorgrav - [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: Step5, pam_opie OPIE auth fix for review
On Mon, Jan 21, 2002 at 01:42:00 +0100, Dag-Erling Smorgrav wrote: The admin can't enforce always OPIE for a user, because the user can always delete his ~/.opiealways. This is per-machine choice. Long time ago, for S-KEY, it was per-terminal choice too, but OPIE currently not have per-terminal module. There is no needs to enforce it for user logged from trusted machine since whole machine is trusted. But paranoid users can enforce it for themselfs. How about I write a pam_opieaccess(8) module and you tell me what you think of it? It's really the cleanest solution from PAM's point of view. Ok, I'll write it and send for review. -- Andrey A. Chernov http://ache.pp.ru/ To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: Step5, pam_opie OPIE auth fix for review
On Mon, Jan 21, 2002 at 03:49:08 +0300, Andrey A. Chernov wrote: How about I write a pam_opieaccess(8) module and you tell me what you think of it? It's really the cleanest solution from PAM's point of view. Ok, I'll write it and send for review. Oops, some keyboard slip. I mean: Ok, write it and I can review it. BTW, I can write it to, back to slip meaning. -- Andrey A. Chernov http://ache.pp.ru/ To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: Step5, pam_opie OPIE auth fix for review
On Mon, Jan 21, 2002 at 01:45:37 +0100, Dag-Erling Smorgrav wrote: No. The [...] form is a Linux-PAM invention, and is tightly linked to Linux-PAM implementation details. It does not exist in other PAM implementations. I aim to move *away* from dependence on Linux-PAM, not *towards* it. Well, I understand. -- Andrey A. Chernov http://ache.pp.ru/ To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
GDB maintainer?
Who is the current GDB maintainer? -Kip __ Do You Yahoo!? Send FREE video emails in Yahoo! Mail! http://promo.yahoo.com/videomail/ To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: Step5, pam_opie OPIE auth fix for review
Andrey A. Chernov [EMAIL PROTECTED] writes:
On Mon, Jan 21, 2002 at 01:42:00 +0100, Dag-Erling Smorgrav wrote:
The admin can't enforce always OPIE for a user, because the user can
always delete his ~/.opiealways.
This is per-machine choice. Long time ago, for S-KEY, it was per-terminal
choice too, but OPIE currently not have per-terminal module.
There is no needs to enforce it for user logged from trusted machine since
whole machine is trusted.
I'm sorry, but in my opinion that should really be the admin's
decision. You can trust a machine without necessarily trusting users
coming from that machine to pick good passwords.
How about I write a pam_opieaccess(8) module and you tell me what you
think of it? It's really the cleanest solution from PAM's point of
view.
Ok, I'll write it and send for review.
No need. See the attached patch.
DES
--
Dag-Erling Smorgrav - [EMAIL PROTECTED]
Index: Makefile
===
RCS file: /home/ncvs/src/lib/libpam/modules/Makefile,v
retrieving revision 1.15
diff -u -r1.15 Makefile
--- Makefile 5 Dec 2001 15:55:14 - 1.15
+++ Makefile 21 Jan 2002 00:46:54 -
@@ -34,6 +34,7 @@
.endif
SUBDIR+= pam_nologin
SUBDIR+= pam_opie
+SUBDIR+= pam_opieaccess
SUBDIR+= pam_permit
SUBDIR+= pam_radius
SUBDIR+= pam_rootok
Index: pam_opie/pam_opie.8
===
RCS file: /home/ncvs/src/lib/libpam/modules/pam_opie/pam_opie.8,v
retrieving revision 1.4
diff -u -r1.4 pam_opie.8
--- pam_opie/pam_opie.8 14 Jul 2001 08:38:24 - 1.4
+++ pam_opie/pam_opie.8 21 Jan 2002 01:18:58 -
@@ -1,5 +1,13 @@
.\ Copyright (c) 2001 Mark R V Murray
.\ All rights reserved.
+.\ Copyright (c) 2002 Networks Associates Technologies, Inc.
+.\ All rights reserved.
+.\
+.\ Portions of this software were developed for the FreeBSD Project by
+.\ ThinkSec AS and NAI Labs, the Security Research Division of Network
+.\ Associates, Inc. under DARPA/SPAWAR contract N66001-01-C-8035
+.\ (CBOSS), as part of the DARPA CHATS research program.
+.\
.\
.\ Redistribution and use in source and binary forms, with or without
.\ modification, are permitted provided that the following conditions
@@ -9,6 +17,9 @@
.\ 2. Redistributions in binary form must reproduce the above copyright
.\notice, this list of conditions and the following disclaimer in the
.\documentation and/or other materials provided with the distribution.
+.\ 3. The name of the author may not be used to endorse or promote
+.\products derived from this software without specific prior written
+.\permission.
.\
.\ THIS SOFTWARE IS PROVIDED BY THE AUTHOR AND CONTRIBUTORS ``AS IS'' AND
.\ ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE
@@ -47,6 +58,13 @@
.Dq Li auth
feature.
It also provides a null function for session management.
+.Pp
+Note that this module does not enforce
+.Xr opieaccess 5
+checks.
+There is a separate module,
+.Xr pam_opieaccess 8 ,
+for this purpose.
.Ss OPIE Authentication Module
The OPIE authentication component
provides functions to verify the identity of a user
Index: pam_opieaccess/Makefile
===
RCS file: pam_opieaccess/Makefile
diff -N pam_opieaccess/Makefile
--- /dev/null 1 Jan 1970 00:00:00 -
+++ pam_opieaccess/Makefile 21 Jan 2002 00:53:49 -
@@ -0,0 +1,10 @@
+# $FreeBSD$
+
+LIB= pam_opieaccess
+SHLIB_NAME= ${LIB}.so
+SRCS= ${LIB}.c
+DPADD= ${LIBOPIE}
+LDADD= -lopie
+MAN= pam_opieaccess.8
+
+.include bsd.lib.mk
Index: pam_opieaccess/pam_opieaccess.8
===
RCS file: pam_opieaccess/pam_opieaccess.8
diff -N pam_opieaccess/pam_opieaccess.8
--- /dev/null 1 Jan 1970 00:00:00 -
+++ pam_opieaccess/pam_opieaccess.8 21 Jan 2002 01:19:01 -
@@ -0,0 +1,108 @@
+.\ Copyright (c) 2001 Mark R V Murray
+.\ All rights reserved.
+.\ Copyright (c) 2002 Networks Associates Technologies, Inc.
+.\ All rights reserved.
+.\
+.\ Portions of this software were developed for the FreeBSD Project by
+.\ ThinkSec AS and NAI Labs, the Security Research Division of Network
+.\ Associates, Inc. under DARPA/SPAWAR contract N66001-01-C-8035
+.\ (CBOSS), as part of the DARPA CHATS research program.
+.\
+.\
+.\ Redistribution and use in source and binary forms, with or without
+.\ modification, are permitted provided that the following conditions
+.\ are met:
+.\ 1. Redistributions of source code must retain the above copyright
+.\notice, this list of conditions and the following disclaimer.
+.\ 2. Redistributions in binary form must reproduce the above copyright
+.\notice, this list of conditions and the following disclaimer in the
+.\documentation and/or other materials provided with the distribution.
+.\ 3. The name of the author may not be used to endorse or promote
+.\products derived from this software without
Re: Step5, pam_opie OPIE auth fix for review
On Mon, Jan 21, 2002 at 02:21:34 +0100, Dag-Erling Smorgrav wrote:
No need. See the attached patch.
Tested. I use /etc/pam.d/login for test with following OPIE lines:
authsufficient pam_opie.so no_warn
authrequisite pam_opieaccess.so no_warn
Two problems found, patch included below.
1) When OPIE turned on in the system, not neccessary all users are
OPIE-ed, only those who listed in /etc/opiekeys. It means that
pam_opieaccess() module must do something only for valid OPIE users
listed in /etc/opiekeys and do nothing for others. I use opiechallenge()
check for it, and if it fails, return PAM_IGNORE.
2) opiealways() return just opposite to what you might expect, see
/usr/src/contrib/opie/libopie/accessfile.c comment about it. Fixed by
removing !
Besides this two things, all works as expected.
--- pam_opieaccess.c.oldMon Jan 21 04:35:08 2002
+++ pam_opieaccess.cMon Jan 21 05:47:27 2002
@@ -55,8 +55,10 @@
PAM_EXTERN int
pam_sm_authenticate(pam_handle_t *pamh, int flags, int argc, const char **argv)
{
+ struct opie opie;
struct options options;
struct passwd *pwent;
+ char challenge[OPIE_CHALLENGE_MAX];
char *luser, *rhost;
int r;
@@ -64,22 +66,32 @@
PAM_LOG(Options processed);
- r = pam_get_item(pamh, PAM_RHOST, (const void **)rhost);
- if (r != PAM_SUCCESS)
- PAM_RETURN(r);
- if (rhost == NULL)
- PAM_RETURN(PAM_SYSTEM_ERR);
-
r = pam_get_item(pamh, PAM_USER, (const void **)luser);
if (r != PAM_SUCCESS)
PAM_RETURN(r);
if (luser == NULL)
PAM_RETURN(PAM_SYSTEM_ERR);
+ /*
+* Don't call the OPIE atexit() handler when our program exits,
+* since the module has been unloaded and we will SEGV.
+*/
+ opiedisableaeh();
+
+ if (opiechallenge(opie, (char *)luser, challenge) != 0)
+ PAM_RETURN(PAM_IGNORE);
+ opieunlock();
+
+ r = pam_get_item(pamh, PAM_RHOST, (const void **)rhost);
+ if (r != PAM_SUCCESS)
+ PAM_RETURN(r);
+ if (rhost == NULL)
+ PAM_RETURN(PAM_SYSTEM_ERR);
+
if ((pwent = getpwnam(luser)) == NULL)
PAM_RETURN(PAM_SYSTEM_ERR);
- if (opieaccessfile(rhost) !opiealways(pwent-pw_dir))
+ if (opieaccessfile(rhost) opiealways(pwent-pw_dir))
PAM_RETURN(PAM_IGNORE);
PAM_VERBOSE_ERROR(Refused; remote host is not in opieaccess);
--
Andrey A. Chernov
http://ache.pp.ru/
To Unsubscribe: send mail to [EMAIL PROTECTED]
with unsubscribe freebsd-current in the body of the message
Re: Step5, pam_opie OPIE auth fix for review
BTW, I have a doubt about PAM_SYSTEM_ERR code you use in several places like this: if (luser == NULL) PAM_RETURN(PAM_SYSTEM_ERR); Please explain two moments: 1) What is stack reaction on this option? Is it the same like PAM_AUTH_ERR reaction or not? 2) Can PAM_SYSTEM_ERR be returned by pam_authenticate() ? If yes. login.c and ftpd.c must be fixed to add this code. -- Andrey A. Chernov http://ache.pp.ru/ To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Hi Friend
Warning Unable to process data: multipart/mixed;boundary==_NextPart_000_1B37_2A92.1000
Re: Diskless Boot Working in -Current ??
I use diskless booting daily on 5.0-CURRENT, and after some tweaks to rc.diskless[12] (now committed) it works just fine. In 5.0-CURRENT, FFS is used directly over malloc disks (md) to support local storage. You should be able to configure netbooing on 5.0 in much the same way as RELENG_4. Are you having a specific problem, or is this just an is this possible?? Thanks, Robert N M Watson FreeBSD Core Team, TrustedBSD Project [EMAIL PROTECTED] NAI Labs, Safeport Network Services On Sun, 20 Jan 2002, Glenn Gombert wrote: I have several kernels built using v4.3 that boot fine over an etherboot/NFS network but a kernel built using GENERIC (with the necesary options added to diskless booting, does not seem to boot), also the option 'MFS' (Memory File System) seems to have been removed from -CURRENT for some reason this is necessary for DISKLESS NFS booting isn't it ??. To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: Current Etherboot
Most people I know of that netboot boxes on Intel platforms now use PXE. With PXE config, the pxe loader has full access to the NFS-mounted /boot directory, so there's no reason to compile in the hints. Robert N M Watson FreeBSD Core Team, TrustedBSD Project [EMAIL PROTECTED] NAI Labs, Safeport Network Services On Sun, 20 Jan 2002, Glenn Gombert wrote: etherboot runs fine on Current, all that is required if to have the 'device.hints' statically compiled into the kernel you are trying to boot: #To statically compile in device wiring instead of /boot/device.hints hints NETBOOT.hints #Default places to look for devices. bit strange that the 'regulars' on the list didn't seem to know about this ... Glenn Gombert [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
__stderrp error
Lots of my old programs get: /usr/libexec/ld-elf.so.1: /usr/local/lib/libpng.so.3: Undefined symbol __stderrp this is NOT the error in UPDATING and doing what it says for a similar problem: 20010924: The buildworld has been fixed. You may need to install the 4.x compatibility libraries for some old binaries to work. Add COMPAT4X=true to your /etc/make.conf to get them installed on every installworld, or execute the following to get them installed only once: cd src/lib/compat/compat4x.arch make all install You will see ``__stdoutp undefined'' until you do this. has NO effect whatsoever. The only thign I can do is recompile any package that has thos problem. but sometimes it's hard finding which package needs to be recomiled. thoughts? To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: __stderrp error
Julian Elischer heeft op maandag 21 januari 2002 om 08:34 het volgende geschreven: Lots of my old programs get: /usr/libexec/ld-elf.so.1: /usr/local/lib/libpng.so.3: Undefined symbol __stderrp this is NOT the error in UPDATING [...] It isn't? It's related. I've seen it before. Setting COMPAT4X worked for me... Are you sure you made the FreeBSD compat libraries? Setting it in make.conf is one thing, but the libraries must be there too :-) Either a make world with COMPAT4X set, or building the 4.x compat libs (for location, see UPDATING), but I guess you knew that. If I'm wrong, let me know :-) Cheers, Emiel To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: __stderrp error
On Mon, 21 Jan 2002, Emiel Kollof wrote: Julian Elischer heeft op maandag 21 januari 2002 om 08:34 het volgende geschreven: Lots of my old programs get: /usr/libexec/ld-elf.so.1: /usr/local/lib/libpng.so.3: Undefined symbol __stderrp this is NOT the error in UPDATING [...] It isn't? It's related. I've seen it before. Setting COMPAT4X worked for me... Are you sure you made the FreeBSD compat libraries? Setting it in make.conf is one thing, but the libraries must be there too :-) Either a make world with COMPAT4X set, or building the 4.x compat libs (for location, see UPDATING), but I guess you knew that. Here is my make.conf.. [...] #COMPAT20= yes #COMPAT21= yes #COMPAT22= yes COMPAT4X= yes # # [...] and I've made world a lot of times like that. and if I do it by hand as sugested, it doesn;t make any difference either. If I'm wrong, let me know :-) Cheers, Emiel To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
