On Mon, Jan 21, 2002 at 01:55:53PM -0800, Terry Lambert wrote:
Jacques A. Vidrine wrote:
In the way that the author of the PAM architecture from Sun
spoke at the Silicon Valley BSD User's Group meeting,
Do you have a reference, or do we have to guess what you are talking
about? :-)
Andrey A. Chernov [EMAIL PROTECTED] writes:
Please explain two moments:
1) What is stack reaction on this option? Is it the same like PAM_AUTH_ERR
reaction or not?
Yes.
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 [EMAIL PROTECTED] writes:
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
On Mon, Jan 21, 2002 at 13:54:29 +0100, Dag-Erling Smorgrav wrote:
Umm, you can't use opiechallenge() for that. You're not supposed to
call opiechallenge() without also calling opieverify() (plus, I think
No, it is possible, when opieunlock() called afterwards (as I do).
BTW, the same way
This is looking good!
Please keep a close eye on style (there is at least one assignment in
an if () statement that needs to move out. :-)
M
--=-=-=
Dag-Erling Smorgrav [EMAIL PROTECTED] writes:
Umm, you can't use opiechallenge() for that. You're not supposed to
call opiechallenge()
On Mon, Jan 21, 2002 at 14:07:48 +0100, Dag-Erling Smorgrav wrote:
Dag-Erling Smorgrav [EMAIL PROTECTED] writes:
Umm, you can't use opiechallenge() for that. You're not supposed to
call opiechallenge() without also calling opieverify() (plus, I think
opiechallenge() consumes a challenge).
On Mon, Jan 21, 2002 at 14:07:48 +0100, Dag-Erling Smorgrav wrote:
Dag-Erling Smorgrav [EMAIL PROTECTED] writes:
Umm, you can't use opiechallenge() for that. You're not supposed to
call opiechallenge() without also calling opieverify() (plus, I think
opiechallenge() consumes a
On Sun, Jan 20, 2002 at 11:43:28PM -0800, Terry Lambert wrote:
Once you guys have this all hammered out, are you going to
integrate PAM and Kerberos? 8-) 8-) 8-).
In what way do you mean?
--
Jacques A. Vidrine [EMAIL PROTECTED] http://www.nectar.cc/
NTT/Verio SME .
Jacques A. Vidrine wrote:
On Sun, Jan 20, 2002 at 11:43:28PM -0800, Terry Lambert wrote:
Once you guys have this all hammered out, are you going to
integrate PAM and Kerberos? 8-) 8-) 8-).
In what way do you mean?
In the way that the author of the PAM architecture from Sun
spoke at
On Mon, Jan 21, 2002 at 12:48:39PM -0800, Terry Lambert wrote:
Jacques A. Vidrine wrote:
On Sun, Jan 20, 2002 at 11:43:28PM -0800, Terry Lambert wrote:
Once you guys have this all hammered out, are you going to
integrate PAM and Kerberos? 8-) 8-) 8-).
In what way do you mean?
Jacques A. Vidrine wrote:
In the way that the author of the PAM architecture from Sun
spoke at the Silicon Valley BSD User's Group meeting,
Do you have a reference, or do we have to guess what you are talking
about? :-)
I have my memory of the talk he gave, which included the idea
that
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
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
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
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.
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
35 matches
Mail list logo
