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
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.
---
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
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
+++
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
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
+++
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
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
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.
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
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
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)',
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 your patch.
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
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
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.
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
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
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
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
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
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
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 stack to make
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
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
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
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
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
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
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
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
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
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
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.
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
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
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
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
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,
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.
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
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
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
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
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]
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
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
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
[...]
57 matches
Mail list logo
