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 i
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_uni
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
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..
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.
"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.
"Andrey A. Chernov" <[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 may allow user to ente
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_opi
> 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.
Thi
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
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
some
> 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 automaticall
"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
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_authenticat
> 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(fo
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
"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 y
> 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 i
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
On Sun, Jan 20, 2002 at 21:07:14 +0100, Dag-Erling Smorgrav wrote:
> 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
"Andrey A. Chernov" <[EMAIL PROTECTED]> writes:
> Yes, but I mean edge case when password yet not expired at the moment of
> pam_acct_mgmt() call (i.e. pam_acct_mgmt() not return
> PAM_AUTHTOK_EXPIRED), but expired at the moment of pam_authenticate()
> call. There can be big network delay betwee
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 withdr
> 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).
>
> Y
On Sun, Jan 20, 2002 at 20:17:21 +, Mark Murray wrote:
>
> Hmm. OK. Do you understand, though, why the salt does not need
> cryptographic randomness?
Yes.
> Another patch of yours replaced sprintf with a faster strlcpy,
> but this uses the _much_ slower arc4random() which is not
> necessary
> > 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. Some
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
"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 any
> > 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.
>
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
On 2002-Jan-20 21:51:07 +, Mark Murray <[EMAIL PROTECTED]> wrote:
>> > 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 effectivel
> 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
>
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
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
> 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 stac
"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 unde
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
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 authen
> 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
>
On Mon, Jan 21, 2002 at 00:56:46 +0100, Dag-Erling Smorgrav wrote:
>
> 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.
> 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 U
"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 configure
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 authent
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 o
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 flexi
> "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
--
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
"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
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-ditc
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
"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
"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 differenc
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-
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
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
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 bo
"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-te
On Mon, Jan 21, 2002 at 02:21:34 +0100, Dag-Erling Smorgrav wrote:
>
> 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.
I not advocate some my position here, I
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
I don't know what mailing list this mail should be
posted to, sorry if it is posted to the wrong mailing
list.
Recently I found Linux 2.4 kernel is affected by the
bug of extended paging in AMD Athlon through the
following link. I don't know if FreeBSD is also
affected.
http://linuxtoday.com/ne
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_
Warning
Unable to process data:
multipart/mixed;boundary="=_NextPart_000_1B37_2A92.1000"
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
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] N
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 compati
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 speciali
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. Se
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
67 matches
Mail list logo
