Subject: Re: Re: lib/30923
To: Rui Paulo <rpaulo@NetBSD.org>
From: John Nemeth <firstname.lastname@example.org>
Date: 08/24/2005 21:34:01
On Jan 14, 9:46pm, Rui Paulo wrote:
} On 2005.08.24 18:36:40 +0000, John Nemeth wrote:
} | On Jan 14, 8:57pm, Rui Paulo wrote:
} | } On 2005.08.24 17:39:34 +0000, John Nemeth wrote:
} | } | On Jan 14, 8:01pm, Rui Paulo wrote:
} | } | } On 2005.08.24 14:44:20 +0000, John Nemeth wrote:
} | } | } | That would be a significantly more complex patch. If I get =
} | } | } | I may dig into login.c a little deeper and figure out how to do t=
} | } | } | However, I wonder if it is worth it, considering that this will s=
} oon be
} | } | } | legacy code?
} | } | }
} | } | } Why will it be soon "legacy code" ?
} | } |
} | } | That might be a little strong. However, consider that 3.0 will
} | } | most likely be out sometime this year. 3.0 onwards will use PAM which
} | } | does authentication completely differently. Take a look in
} | } | src/usr.bin/login. There you will see login.c and login_pam.c.
} | } | login.c handles tradational methods, i.e. 2.x and earlier (also, if y=
} | } | do a custom build without PAM). login_pam.c handles PAM, i.e. 3.0 and
} | } | onwards.
} | }=20
} | } I see your point.
} | }=20
} | } | BTW, I see that you have a NetBSD.org address. Could you commit
} | } | these patches? Or, is monkeying with security related stuff too far
} | } | outside the areas that you normally work on?
} | }=20
} | } Which patches? I still believe we need another way of handling this.
} | } login.conf is an idea; anyone else wants to comment on that ?
} | I provided patches for both login.c and login_pam.c to stop login
} | from giving different messages for correct and incorrect passwords when
} | logging in as root on an insecure terminal. Both patches are floating
} | around in this thread.
} Yes, but they just change a printf message IIRC.
That's all that is required to fix the reported problems.
} | Now that I think about it, I don't think login.conf should be
} | involved in any of this. The secure flag in /etc/ttys determines if
} | one should be allowed to login as root on a given terminal. Or, do you
} | want to use login.conf to dictate if a different message should be
} | displayed for the cases of correct and incorrect password? I really
} | don't think this is necessary.
} I think the thread was all about the output message and the "secure" point
} of view of it. While I don't care much about the message printed, someone
} may want that as an option.
The thread was about getting a different message when you enter
the correct password as opposed to when you enter an incorrect address
while trying to login as root on an insecure terminal. The patches fix
it so that you get the same message for both cases, thus solving the
problem that was reported.
}-- End of excerpt from Rui Paulo