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
>
"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 ide
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
"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
sp
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
> 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() "con
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 c
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 opiechall
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
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). Use opielookup() instead.
Even better, opie_haskey() (which is
"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 fo
"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 thi
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
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_
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
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
"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 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
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: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-
"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
"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
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
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
"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
> "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
--
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
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
"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
> 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
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.
> 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
>
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
> > pam_opie
"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: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
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
> 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
>
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
39 matches
Mail list logo
