Re: [TCLUG:10372] telnet over network

[Karl Morgan <ksm@dogbrain.com>]

After thinking about it for a bit it's obvious that the pam_securetty
module isn't working correctly. Or, you should be able to list the
ttys where root can login in the /etc/securetty file and have it work.

The fact that you suggest editing the /etc/pam.d/login file, and I
suggest messing with /etc/securetty is basically the same thing.
But then again, if it was working correctly niether of these actions
would be necessary now would it?

And as for the post, the original question that started all of this,
Both the offerred solutions work, mine requires less key strokes,
and I know it works. There are multiple ways to do most anything 
on/with unix.

So are you going to do the *right* thing from the start and open
a bug with redhat?

Regards

					- Karl

> On Mon, Nov 22, 1999 at 09:49:27PM -0600, Karl Morgan wrote:
> > 
> > And I stand by that statement, but you are right. Login isn't
> > responsible for this function anymore. I did a quick check and it is
> > pam that is looking in /etc/securetty from the pam_securetty
> > module. And the effect is the same, if you move /etc/securetty out of
> > the way, root can login on any tty.
> 
> 	I agree that it'll work, but I think it's better just to tell
> pam to not pay attention to the securetty file rather than to change its
> name so it can't be found.
> 
> 	Like I said, maybe something other than pam pays attention to
> the securetty file, and that could have painful, surprising consequences
> later.  The man page for the securetty file hasn't been updated since
> December of 1992.
> 
> 	It's much more precise and to the point to change the pam file
> for 'login'.  It says "I don't want login to care if I'm on a securetty
> or not", which is exactly what you want to say.  Moving the securetty
> file is saying 'All of my ttys are secure', which isn't that same thing
> at all.
> 
> 	Sorry to be a pain about it, but these kinds of decisions can
> have big consequences down the line, and the best time to start doing it
> right is right at the beginning.  Less things to fix later that way.
> Yeah, moving securetty back is an easy thing to do, but the problem is,
> when do you do it?  Obviously when you want to disallow root telnets,
> but how about if you're experiencing some weird, inexplicable problem or
> security hole.  It isn't so obvious then.
> 
> Have fun (if at all possible),
>