Bug#332198: [Pkg-shadow-devel] login: unable to determine TTY name, got /dev/pts/1

[Alexander Gattin]

Hello, thanks for your explanations!

On Fri, Oct 07, 2005 at 07:30:12AM +0200, Marc Lehmann wrote:
> On Wed, Oct 05, 2005 at 06:13:58PM +0200, Christian Perrier <bubulle at debian.org> wrote:
> > Can you try reproducing this with login and passwd packages from sid ?
> 
> It happens with this version, too:
> 
> ii  login                              4.0.11.1-1 system login tools
> ii  passwd                             4.0.11.1-1 change and administer password and group data

So I think this will happen with all current versions
of login/passwd.

> If you want, I can test with 4.0.12 if there are important changes between
> 4.0.11 and .12.

I think we need:
1) to change the error message to smth. more suitable
   // this would probably be propagaed to upstream
2) to add debug statements to the newest login
   // this I think could be left Debian-specific
   and after this we would like you to test the new
   version.

> > It also seems that you're trying to rsh from root to root on another
> > host.
> Yes.

Does the bug appear when you login locally
(localhost->localhost)? Do you think it _can_ at all be
seen with localhost logins (or I need 2 host setup in
order to test)?

> > Despite being highly insecure,
> 
> Despite this being untrue and not substantiatable, people like to repeat
> this kind of non-fact often

We can discuss this more if you like, but I really
beleive that any auth without kind of host keys
involved (like in krb/ssh/ssl/ipsec) is insecure, prone
to MITM or even IP spoofing (when in the same broadcast
domain). But anyway this is irrelevant to the problem
and many people including me still use some kind of
"insecure" environments like NIS.

> > have you checked the contents of
> > /etc/securetty on the target machine?
> 
> It does not contain any pts/* entries, but that doesn't matter,

Because you commented out pam_securetty.so, I see.

> > I actually think that the "unable to determine TTY name" from login is
> > maybe not *the* cause of the problem.
> That might very well be. I do not see that message, however, when it works

Christian meant, I think, that this message indicates
the problem but is not the cause of it, i.e. most
probably (and I agree here) the source is some external
to the login/passwd issue, like
devfs/devpts/udevd/initrd/libpam or alike.

> (probably >>99.999% of the time), and I have the syslog from my machines
> onscreen most of the time, so it is at least a hint on the problem, even if
> it's just another symptom.

Of course.
login makes chowntty and thus is very picky about it
(citing libmisc/chowntty.c):
> 	if (!is_my_tty (tty)) {
> 		SYSLOG ((LOG_WARN,
> 			 "unable to determine TTY name, got %s\n", tty));
> 		closelog ();
> 		exit (1);
> 	}
going further, we see the next:
> /*
>  * is_my_tty -- determine if "tty" is the same as TTY stdin is using
>  */
> static int is_my_tty (const char *tty)
> {
> 	struct stat by_name, by_fd;
> 
> 	if (stat (tty, &by_name) || fstat (0, &by_fd))
> 		return 0;
> 
> 	if (by_name.st_rdev != by_fd.st_rdev)
> 		return 0;
> 	else
> 		return 1;
> }
As you can see, either one of stats failed or rdevs
were different (and this is strange) -- that's why you
get "unable to determine TTY name" message.

I'll perhaps just add "SYSLOG ((LOG_DEBUG, ..." there
in order to have more specific info on the issue (your
help will be required to debug this).

But first I'll try to mimic your setup as close as
possible and try to hit the problem myself.

I have summarised remaining questions below, first my
assumptions:
A. let's take 2 hosts -- cerebro and fuji
   * you run `rlogin fuji` as root at cerebro
   * you have "cerebro root" in ~/.rhosts at fuji
     (BTW, I also made a .rhosts file imediately to test
     your report)
   * "pam_rhosts_auth.so suppress no_hosts_equiv" and pam_securetty.so
     commented out are your only customisations to distributive's
     /etc/pam.d/rlogin
now questions:
1. you have rsh-client on cerebro and [since now]
   rsh-server on fuji?
2. you have 3 mentions of /dev/tty[35] (!!!) in logs
   -- do you have any clue why the hell are they there?
   Did you had strange login denials on virtual console?
3. in first report you mentioned that you hit the
   problem after rebooting (fuji, AFAIU?) and trying to
   execute `rlogin fuji`. Generally, I was under
   impression that the problem happens _more_
   frequently after fuji's reboot. Maybe it's because
   you just rlogin there most frequently only after
   reboot?
4. I forgot to ask what is in fuji:/etc/pam.d/login?
   (and in relevant files like common-auth if any)
5. version of inetd?
6. what is configuration line for in.rlogind in inetd.conf?
7. do you have something unusual like chroot, devfs or
   uncommon rootfs like YAFFS or JFFS2?

P.S. I wrote expect script to test repeated rlogins,
but 'cause I'm not an expect guru I still don't know
how to stop expect script by e.g. ctrl-C...
-- 
WBR,
xrgtn