Acknowledgement sent to Marc Lehmann <debian-reportbug@plan9.de>:
New Bug report received and forwarded. Copy sent to Shadow package maintainers <pkg-shadow-devel@lists.alioth.debian.org>.
(full text, mbox, link).
To: Debian Bug Tracking System <submit@bugs.debian.org>
Subject: login: unable to determine TTY name, got /dev/pts/1
Date: Wed, 05 Oct 2005 06:23:15 +0200
Package: login
Version: 1:4.0.3-35
Severity: normal
Directly after a fresh reboot eeboot, "rsh rebooted-host" results in an
immediate connection close, and the syslog on the remote host says:
Oct 5 06:12:36 cerebro in.rlogind: Connection from root@fuji for root
Oct 5 06:12:36 cerebro pam_rhosts_auth[452]: allowed to root@fuji as root
Oct 5 06:12:36 cerebro login[453]: (pam_unix) session opened for user root by root(uid=0)
> Oct 5 06:12:36 cerebro login[453]: unable to determine TTY name, got /dev/pts/1
Oct 5 06:12:36 cerebro in.rlogind[452]: Closing connection with root@fuji
"/dev/pts/1" looks like a perfectly fine tty name to me. Subsequent rsh
calls work fine.
I think at least the error message should be clearer, right now it is
wrong, as it did correctly determine the tty name, and something else
failed.
-- System Information:
Debian Release: testing/unstable
APT prefers testing
APT policy: (700, 'testing'), (500, 'unstable'), (500, 'stable'), (1, 'experimental')
Architecture: i386 (i686)
Shell: /bin/sh linked to /bin/dash
Kernel: Linux 2.6.12.3
Locale: LANG=C, LC_CTYPE=de_DE.UTF-8 (charmap=UTF-8)
Versions of packages login depends on:
hi libc6 2.3.5-6 GNU C Library: Shared libraries an
ii libpam-modules 0.76-23 Pluggable Authentication Modules f
ii libpam-runtime 0.76-23 Runtime support for the PAM librar
ii libpam0g 0.76-23 Pluggable Authentication Modules l
login recommends no packages.
-- no debconf information
Information forwarded to debian-bugs-dist@lists.debian.org, Shadow package maintainers <pkg-shadow-devel@lists.alioth.debian.org>: Bug#332198; Package login.
(full text, mbox, link).
Acknowledgement sent to Christian Perrier <bubulle@debian.org>:
Extra info received and forwarded to list. Copy sent to Shadow package maintainers <pkg-shadow-devel@lists.alioth.debian.org>.
(full text, mbox, link).
Quoting Marc Lehmann (debian-reportbug@plan9.de):
> Package: login
> Version: 1:4.0.3-35
> Severity: normal
>
>
> Directly after a fresh reboot eeboot, "rsh rebooted-host" results in an
> immediate connection close, and the syslog on the remote host says:
>
> Oct 5 06:12:36 cerebro in.rlogind: Connection from root@fuji for root
> Oct 5 06:12:36 cerebro pam_rhosts_auth[452]: allowed to root@fuji as root
> Oct 5 06:12:36 cerebro login[453]: (pam_unix) session opened for user root by root(uid=0)
> > Oct 5 06:12:36 cerebro login[453]: unable to determine TTY name, got /dev/pts/1
> Oct 5 06:12:36 cerebro in.rlogind[452]: Closing connection with root@fuji
>
> "/dev/pts/1" looks like a perfectly fine tty name to me. Subsequent rsh
> calls work fine.
>
> I think at least the error message should be clearer, right now it is
> wrong, as it did correctly determine the tty name, and something else
Can you try reproducing this with login and passwd packages from sid ?
Etch (testing) currently still has the old 4.0.3 version we had in
sarge and the gap with 4.0.12 which is in sid is huge.
It also seems that you're trying to rsh from root to root on another
host.
Despite being highly insecure, have you checked the contents of
/etc/securetty on the target machine?
I actually think that the "unable to determine TTY name" from login is
maybe not *the* cause of the problem.
Information forwarded to debian-bugs-dist@lists.debian.org, Shadow package maintainers <pkg-shadow-devel@lists.alioth.debian.org>: Bug#332198; Package login.
(full text, mbox, link).
Acknowledgement sent to Alexander Gattin <xrgtn@yandex.ru>:
Extra info received and forwarded to list. Copy sent to Shadow package maintainers <pkg-shadow-devel@lists.alioth.debian.org>.
(full text, mbox, link).
tags 332198 moreinfo
thanks
What are versions of dash, rsh-client and rsh-server
used?
On Wed, Oct 05, 2005 at 06:13:58PM +0200, Christian Perrier wrote:
> Quoting Marc Lehmann (debian-reportbug@plan9.de):
> > Version: 1:4.0.3-35
> >
> >
> > Directly after a fresh reboot eeboot, "rsh rebooted-host" results in an
> > immediate connection close, and the syslog on the remote host says:
> >
> > Oct 5 06:12:36 cerebro in.rlogind: Connection from root@fuji for root
> > Oct 5 06:12:36 cerebro pam_rhosts_auth[452]: allowed to root@fuji as root
> > Oct 5 06:12:36 cerebro login[453]: (pam_unix) session opened for user root by root(uid=0)
> > > Oct 5 06:12:36 cerebro login[453]: unable to determine TTY name, got /dev/pts/1
> > Oct 5 06:12:36 cerebro in.rlogind[452]: Closing connection with root@fuji
> >
> > "/dev/pts/1" looks like a perfectly fine tty name to me. Subsequent rsh
> > calls work fine.
> >
> > I think at least the error message should be clearer, right now it is
> > wrong, as it did correctly determine the tty name, and something else
>
> Can you try reproducing this with login and passwd packages from sid ?
I tried with new login, rlogin-ed OK on pts/0 and pts/1...
// sh -> bash on my system BTW
> I actually think that the "unable to determine TTY name" from login is
> maybe not *the* cause of the problem.
But after RTFS, I think this error msg is really
misleading...
--
WBR,
xrgtn
Tags added: moreinfo
Request was from Alexander Gattin <xrgtn@yandex.ru>
to control@bugs.debian.org.
(full text, mbox, link).
Information forwarded to debian-bugs-dist@lists.debian.org, Shadow package maintainers <pkg-shadow-devel@lists.alioth.debian.org>: Bug#332198; Package login.
(full text, mbox, link).
Acknowledgement sent to Alexander Gattin <xrgtn@yandex.ru>:
Extra info received and forwarded to list. Copy sent to Shadow package maintainers <pkg-shadow-devel@lists.alioth.debian.org>.
(full text, mbox, link).
Hi!
> What are versions of dash, rsh-client and rsh-server
> used?
Do you use rsh-redone-server or rsh-server?
Do you use rsh-redone-client or rsh-client?
What is in your /etc/pam.d/rsh? /etc/pam.d/rlogin?
> > > Oct 5 06:12:36 cerebro in.rlogind: Connection from root@fuji for root
Well, I don't have such lines from in.rlogind in
my auth.log (I try on localhost)...
> > > "/dev/pts/1" looks like a perfectly fine tty name to me. Subsequent rsh
> > > calls work fine.
Subsequent rsh calls _on /dev/pts/1_?
> > Can you try reproducing this with login and passwd packages from sid ?
>
> I tried with new login, rlogin-ed OK on pts/0 and pts/1...
> // sh -> bash on my system BTW
I tried with login 1:4.0.3-35 and /bin/sh symlinked to
dash -- the same effect, i.e. everything works...
Marc, could you shed more light on your configuration,
please?
--
WBR,
xrgtn
Message sent on to Marc Lehmann <debian-reportbug@plan9.de>:
Bug#332198.
(full text, mbox, link).
Information forwarded to debian-bugs-dist@lists.debian.org, Shadow package maintainers <pkg-shadow-devel@lists.alioth.debian.org>: Bug#332198; Package login.
(full text, mbox, link).
Acknowledgement sent to Marc Lehmann <schmorp@schmorp.de>:
Extra info received and forwarded to list. Copy sent to Shadow package maintainers <pkg-shadow-devel@lists.alioth.debian.org>.
(full text, mbox, link).
On Wed, Oct 05, 2005 at 06:13:58PM +0200, Christian Perrier <bubulle@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
If you want, I can test with 4.0.12 if there are important changes between
4.0.11 and .12.
> It also seems that you're trying to rsh from root to root on another
> host.
Yes.
> Despite being highly insecure,
Despite this being untrue and not substantiatable, people like to repeat
this kind of non-fact often, just like parrots :) What might be insecure
is not rsh, but, say, your root-password, or your wire, or ..., but
rsh/rlogin are not generally less secure than, say, ssh. Claiming it is
does not improve security, because it only makes issues more confusing.
If you meant that seriously, you should first understand what the
insecurities are that are involved in remote login are, and it's not the
rlogin protocol. At least ssh is not generally more secure (it supports
the same modes of authentication, and not every wire can be tapped, nor
does tapping, in generally, lower the security of rsh/rlogin), and people
don't complain about ssh being "highly insecure", either.
> 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 my
pam.d/rlogin file looks like this (should have attached it to the original
report, sorry), and has securetty checks disabled:
#%PAM-1.0
#auth requisite pam_securetty.so
auth sufficient pam_rhosts_auth.so suppress no_hosts_equiv
auth required pam_unix.so nullok
auth required pam_nologin.so
account required pam_unix.so
password required pam_unix.so nullok use_authtok obscure min=4 max=8
session required pam_unix.so
> 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
(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.
--
The choice of a
-----==- _GNU_
----==-- _ generation Marc Lehmann
---==---(_)__ __ ____ __ pcg@goof.com
--==---/ / _ \/ // /\ \/ / http://schmorp.de/
-=====/_/_//_/\_,_/ /_/\_\ XX11-RIPE
Information forwarded to debian-bugs-dist@lists.debian.org, Shadow package maintainers <pkg-shadow-devel@lists.alioth.debian.org>: Bug#332198; Package login.
(full text, mbox, link).
Acknowledgement sent to Marc Lehmann <schmorp@schmorp.de>:
Extra info received and forwarded to list. Copy sent to Shadow package maintainers <pkg-shadow-devel@lists.alioth.debian.org>.
(full text, mbox, link).
On Thu, Oct 06, 2005 at 01:58:05AM +0300, Alexander Gattin <xrgtn@yandex.ru> wrote:
> What are versions of dash, rsh-client and rsh-server
> used?
One both machines:
ii dash 0.5.2-5 The Debian Almquist Shell
ii rsh-redone-server 66-1 Reimplementation of rshd and rlogind
ii rsh-client 0.17-13 rsh clients.
It happens in either direction.
I am myself a bit surprised that those two are still using
rsh-redone-server (both rsh-redone-server and -client caused me much
grieve on my production machines), and I'll switch to the standard
rsh-server and rsh-client packages (the machines with the problem are my
desktop machine and laptop, where I log in remotely less often).
I also installed 1:4.0.12-6 versions of both passwd and login on both
machines, and will have a look on the problem (it is hard to reproduce,
though, as it only happens one every few weeks or so, at daily reboots).
> > Can you try reproducing this with login and passwd packages from sid ?
>
> I tried with new login, rlogin-ed OK on pts/0 and pts/1...
> // sh -> bash on my system BTW
dash here, as you already knew :)
--
The choice of a
-----==- _GNU_
----==-- _ generation Marc Lehmann
---==---(_)__ __ ____ __ pcg@goof.com
--==---/ / _ \/ // /\ \/ / http://schmorp.de/
-=====/_/_//_/\_,_/ /_/\_\ XX11-RIPE
Information forwarded to debian-bugs-dist@lists.debian.org, Shadow package maintainers <pkg-shadow-devel@lists.alioth.debian.org>: Bug#332198; Package login.
(full text, mbox, link).
Acknowledgement sent to Marc Lehmann <schmorp@schmorp.de>:
Extra info received and forwarded to list. Copy sent to Shadow package maintainers <pkg-shadow-devel@lists.alioth.debian.org>.
(full text, mbox, link).
On Thu, Oct 06, 2005 at 10:00:59PM +0300, Alexander Gattin <xrgtn@yandex.ru> wrote:
> > What are versions of dash, rsh-client and rsh-server
> > used?
>
> Do you use rsh-redone-server or rsh-server?
> Do you use rsh-redone-client or rsh-client?
> What is in your /etc/pam.d/rsh? /etc/pam.d/rlogin?
My original report is somewhat confusing, I see now, as I only tested
rlogin (rsh without a command), so rsh should not matter, here is
pam.d/rsh:
#
# The PAM configuration file for the rsh (Remote Shell) service
#
# Due to limitations in the rsh protocol, modules depending on the conversation
# function to work cannot be used. This includes authentication modules such
# as pam_unix.so.
auth required pam_rhosts_auth.so suppress no_hosts_equiv
auth required pam_nologin.so
auth required pam_env.so
account required pam_unix_acct.so
session required pam_limits.so
session required pam_unix_session.so
And here is pam.d/rlogin (as given earlier):
#%PAM-1.0
#auth requisite pam_securetty.so
auth sufficient pam_rhosts_auth.so suppress no_hosts_equiv
auth required pam_unix.so nullok
auth required pam_nologin.so
account required pam_unix.so
password required pam_unix.so nullok use_authtok obscure min=4 max=8
session required pam_unix.so
If it matters, I also use .rhosts-based authentication.
> > > > Oct 5 06:12:36 cerebro in.rlogind: Connection from root@fuji for root
>
> Well, I don't have such lines from in.rlogind in
> my auth.log (I try on localhost)...
That was due to rsh-redone-server (sorry again, I was convinced I had it
replaced everywhere). With rsh-server, it looks like this:
Oct 7 07:43:26 cerebro pam_rhosts_auth[25505]: allowed to root@fuji as root
Oct 7 07:43:26 cerebro login[25506]: (pam_unix) session opened for user root by (uid=0)
Oct 7 07:43:26 cerebro login[25507]: ROOT LOGIN on `pts/7' from `fuji'
> > > > "/dev/pts/1" looks like a perfectly fine tty name to me. Subsequent rsh
> > > > calls work fine.
>
> Subsequent rsh calls _on /dev/pts/1_?
Can't say, but very likely uses a different tty name. I also grepped through
my logs:
Oct 5 06:12:36 cerebro login[453]: unable to determine TTY name, got /dev/pts/1
Sep 23 02:42:46 cerebro login[453]: unable to determine TTY name, got /dev/pts/2
Sep 22 14:00:34 cerebro login[453]: unable to determine TTY name, got /dev/pts/2
Sep 20 12:36:59 cerebro login[453]: unable to determine TTY name, got /dev/pts/2
May 18 15:00:03 cerebro login[442]: unable to determine TTY name, got /dev/pts/1
Apr 25 06:44:50 cerebro login[601]: unable to determine TTY name, got /dev/tty3
Mar 18 14:20:37 cerebro login[468]: unable to determine TTY name, got /dev/pts/4
Feb 24 13:25:00 cerebro login[443]: unable to determine TTY name, got /dev/pts/2
Feb 18 11:56:16 cerebro login[483]: unable to determine TTY name, got /dev/pts/4
Feb 1 14:09:13 cerebro login[411]: unable to determine TTY name, got /dev/pts/2
Jan 21 17:18:24 cerebro login[465]: unable to determine TTY name, got /dev/pts/3
Nov 29 13:48:43 cerebro login[462]: unable to determine TTY name, got /dev/tty5
Sep 30 13:36:22 cerebro login[394]: unable to determine TTY name, got /dev/pts/0
Sep 14 22:41:27 cerebro login[404]: unable to determine TTY name, got /dev/pts/0
Sep 14 22:34:23 cerebro login[404]: unable to determine TTY name, got /dev/pts/0
Aug 31 12:35:40 cerebro login[378]: unable to determine TTY name, got /dev/pts/1
Aug 29 10:19:51 cerebro login[378]: unable to determine TTY name, got /dev/pts/1
Jul 28 14:05:28 cerebro login[402]: unable to determine TTY name, got /dev/pts/86
Jul 12 17:20:03 cerebro login[552]: unable to determine TTY name, got /dev/tty5
As you can see, it's not exactly a frequent message, and seems independent
of the actual tty name and mostly of the login version (I upgrade at
least once/week, and one system is mostly following testing, the other
unstable).
However, I was under the impression that the problem occurs slightly more
often than the message, but such impressions might or might not be wrong,
I certainly don't remember for sure.
It also "haunts" me for a long time, although it wasn't exactly pressing
enough to report it, because I cannot reproduce it. I thought the message
would help finding the problem, but ... :)
> Marc, could you shed more light on your configuration,
> please?
Anything you want to know! The only thing I cannot provide is quick
reproducability, as it works most of the time (you can assume that I
log-in after reboot daily).
Also, it happens even when the machine was already up for, say, 10
minutes, so it doesn't seem like a race between login and the boot
sequence.
--
The choice of a
-----==- _GNU_
----==-- _ generation Marc Lehmann
---==---(_)__ __ ____ __ pcg@goof.com
--==---/ / _ \/ // /\ \/ / http://schmorp.de/
-=====/_/_//_/\_,_/ /_/\_\ XX11-RIPE
Information forwarded to debian-bugs-dist@lists.debian.org, Shadow package maintainers <pkg-shadow-devel@lists.alioth.debian.org>: Bug#332198; Package login.
(full text, mbox, link).
Acknowledgement sent to Marc Lehmann <schmorp@schmorp.de>:
Extra info received and forwarded to list. Copy sent to Shadow package maintainers <pkg-shadow-devel@lists.alioth.debian.org>.
(full text, mbox, link).
On Wed, Oct 05, 2005 at 06:13:58PM +0200, Christian Perrier <bubulle@debian.org> wrote:
> I actually think that the "unable to determine TTY name" from login is
> maybe not *the* cause of the problem.
Lucky day:
cerebro ~/pserv# fuji
rlogin: connection closed.
cerebro ~/pserv# apt-get install xmltv
E: Could not get lock /var/lib/apt/lists/lock - open (11 Resource temporarily unavailable)
E: Unable to lock the list directory
[Exit 100]
cerebro ~/pserv#
[Exit 100]
cerebro ~/pserv# fuji
fuji ~# tail /var/log/messages
Oct 7 07:51:22 fuji named[1126]: USAGE 1128664282 1128426682 CPU=0.050992u/0.041993s CHILDCPU=0.050992u/0.034994s
Oct 7 07:51:22 fuji named[1126]: NSTATS 1128664282 1128426682 A=152 PTR=86
Oct 7 07:51:22 fuji named[1126]: XSTATS 1128664282 1128426682 RR=84 RNXD=7 RFwdR=12 RDupR=1 RFail=0 RFErr=0 RErr=1 RAXFR=0 RLame=0 ROpts=0 SSysQ=79 SAns=145 SFwdQ=103 SDupQ=840 SErr=34 RQ=238 RIQ=0 RFwdQ=103 RDupQ=16 RTCP=0 SFwdR=12 SFail=0 SFErr=0 SNaAns=127 SNXD=42 RUQ=0 RURQ=0 RUXFR=0 RUUpd=0
Oct 7 07:57:11 fuji pam_rhosts_auth[6540]: allowed to root@cerebro as root
Oct 7 07:57:11 fuji login[6541]: (pam_unix) session opened for user root by (uid=0)
Oct 7 07:57:11 fuji login[6542]: ROOT LOGIN on `pts/10' from `cerebro'
Oct 7 07:57:11 fuji login[6541]: (pam_unix) session closed for user root
Oct 7 07:57:18 fuji pam_rhosts_auth[6547]: allowed to root@cerebro as root
Oct 7 07:57:18 fuji login[6548]: (pam_unix) session opened for user root by (uid=0)
Oct 7 07:57:18 fuji login[6549]: ROOT LOGIN on `pts/10' from `cerebro'
Just happened a few minutes ago: I tried to install xmltv on "fuji", and
as you can see the first try failed, the second worked. It was on the same
tty, and long after bootup, and NOT the first login, and finally did not
complain about the tty name.
So there seem to be two problems, my log-in problem and a suboptimal error
message, which are probably independent of each other.
Unfortunately, that was before upgrading to 4.0.12, i.e. still with 4.0.3
(so far it happens with 4.0.11 and 4.0.3).
--
The choice of a
-----==- _GNU_
----==-- _ generation Marc Lehmann
---==---(_)__ __ ____ __ pcg@goof.com
--==---/ / _ \/ // /\ \/ / http://schmorp.de/
-=====/_/_//_/\_,_/ /_/\_\ XX11-RIPE
Message sent on to Marc Lehmann <debian-reportbug@plan9.de>:
Bug#332198.
(full text, mbox, link).
Information forwarded to debian-bugs-dist@lists.debian.org, Shadow package maintainers <pkg-shadow-devel@lists.alioth.debian.org>: Bug#332198; Package login.
(full text, mbox, link).
Acknowledgement sent to Alexander Gattin <xrgtn@yandex.ru>:
Extra info received and forwarded to list. Copy sent to Shadow package maintainers <pkg-shadow-devel@lists.alioth.debian.org>.
(full text, mbox, link).
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@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@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
Owner recorded as Alexander Gattin <arg@online.com.ua>.
Request was from Christian Perrier <bubulle@debian.org>
to control@bugs.debian.org.
(full text, mbox, link).
Information forwarded to debian-bugs-dist@lists.debian.org, Shadow package maintainers <pkg-shadow-devel@lists.alioth.debian.org>, Alexander Gattin <arg@online.com.ua>: Bug#332198; Package login.
(full text, mbox, link).
Acknowledgement sent to Christian Perrier <bubulle@debian.org>:
Extra info received and forwarded to list. Copy sent to Shadow package maintainers <pkg-shadow-devel@lists.alioth.debian.org>, Alexander Gattin <arg@online.com.ua>.
(full text, mbox, link).
To: 332198@bugs.debian.org, 332198-submitter@bugs.debian.org
Subject: Status of this bug
Date: Fri, 6 Jan 2006 18:50:07 +0100
The status of this bug report is kinda confusing.
I absolutely don't know whether someone is still investigating it. I
even don't know if it happens with recent releases of shadow.
In short, this seems to be a nice piece of nasty nightmare which could
lie around for a very long time until someone is really annoyed by
this again.
So, what do we do?
--
Message sent on to Marc Lehmann <debian-reportbug@plan9.de>:
Bug#332198.
(full text, mbox, link).
Information forwarded to debian-bugs-dist@lists.debian.org, Shadow package maintainers <pkg-shadow-devel@lists.alioth.debian.org>, Alexander Gattin <arg@online.com.ua>: Bug#332198; Package login.
(full text, mbox, link).
Acknowledgement sent to Alexander Gattin <xrgtn@yandex.ru>:
Extra info received and forwarded to list. Copy sent to Shadow package maintainers <pkg-shadow-devel@lists.alioth.debian.org>, Alexander Gattin <arg@online.com.ua>.
(full text, mbox, link).
Hi!
On Fri, Jan 06, 2006 at 06:50:07PM +0100, Christian Perrier wrote:
> I absolutely don't know whether someone is still investigating it. I
> even don't know if it happens with recent releases of shadow.
I suspect it does. Sometimes. Actually I think the bug
is caused by /var/tmp/utmp file being corrupt from time
to time.
> In short, this seems to be a nice piece of nasty nightmare which could
> lie around for a very long time until someone is really annoyed by
> this again.
>
> So, what do we do?
I propose to add syslog debug statements in the code
which will provide more information about tty when bug
_happens_. I think we could enable this debugging code
and just distribute the shadow with it compiled in,
because it will increase shadow's verbosity only a bit.
P.S. I have already patched/modified source
(libmisc/chowntty.c) in my working directory of
Tomasz's CVS. Diff against most recent CVS is attached.
You can see that even when error happens the code uses
LOG_DEBUG level.
If you agree upon this behaviour, I'll generate quilt
patch and enable it.
--
WBR,
xrgtn
Message sent on to Marc Lehmann <debian-reportbug@plan9.de>:
Bug#332198.
(full text, mbox, link).
Information forwarded to debian-bugs-dist@lists.debian.org, Shadow package maintainers <pkg-shadow-devel@lists.alioth.debian.org>, Alexander Gattin <arg@online.com.ua>: Bug#332198; Package login.
(full text, mbox, link).
Acknowledgement sent to Marc Lehmann <schmorp@schmorp.de>:
Extra info received and forwarded to list. Copy sent to Shadow package maintainers <pkg-shadow-devel@lists.alioth.debian.org>, Alexander Gattin <arg@online.com.ua>.
(full text, mbox, link).
Subject: Re: Bug#332198: [Pkg-shadow-devel] Bug#332198: Status of this bug
Date: Sat, 7 Jan 2006 09:18:28 +0100
On Sat, Jan 07, 2006 at 12:24:01AM +0200, Alexander Gattin <xrgtn@yandex.ru> wrote:
> Hi!
>
> On Fri, Jan 06, 2006 at 06:50:07PM +0100, Christian Perrier wrote:
> > I absolutely don't know whether someone is still investigating it. I
> > even don't know if it happens with recent releases of shadow.
>
> I suspect it does. Sometimes. Actually I think the bug
> is caused by /var/tmp/utmp file being corrupt from time
> to time.
A theory is better than no theory. In any case, I had this problem once
about a week ago, and I usually update to unstable on those machines every
few weeks at leats, so it still seems to be there.
> I propose to add syslog debug statements in the code
> which will provide more information about tty when bug
> _happens_. I think we could enable this debugging code
> and just distribute the shadow with it compiled in,
> because it will increase shadow's verbosity only a bit.
Great idea!
> You can see that even when error happens the code uses
> LOG_DEBUG level.
>
> If you agree upon this behaviour, I'll generate quilt
> patch and enable it.
I'd be happy to try to reproduce it!
--
The choice of a
-----==- _GNU_
----==-- _ generation Marc Lehmann
---==---(_)__ __ ____ __ pcg@goof.com
--==---/ / _ \/ // /\ \/ / http://schmorp.de/
-=====/_/_//_/\_,_/ /_/\_\ XX11-RIPE
Information stored: Bug#332198; Package login.
(full text, mbox, link).
Acknowledgement sent to Marc Lehmann <schmorp@schmorp.de>:
Extra info received and filed, but not forwarded.
(full text, mbox, link).
Message sent on to Marc Lehmann <debian-reportbug@plan9.de>:
Bug#332198.
(full text, mbox, link).
Information forwarded to debian-bugs-dist@lists.debian.org, Shadow package maintainers <pkg-shadow-devel@lists.alioth.debian.org>, Alexander Gattin <arg@online.com.ua>: Bug#332198; Package login.
(full text, mbox, link).
Acknowledgement sent to Christian Perrier <bubulle@debian.org>:
Extra info received and forwarded to list. Copy sent to Shadow package maintainers <pkg-shadow-devel@lists.alioth.debian.org>, Alexander Gattin <arg@online.com.ua>.
(full text, mbox, link).
To: Marc Lehmann <schmorp@schmorp.de>, 332198@bugs.debian.org
Subject: Re: Bug#332198: [Pkg-shadow-devel] Bug#332198: Status of this bug
Date: Sat, 7 Jan 2006 09:46:13 +0100
> > You can see that even when error happens the code uses
> > LOG_DEBUG level.
> >
> > If you agree upon this behaviour, I'll generate quilt
> > patch and enable it.
>
> I'd be happy to try to reproduce it!
So, Alex, please go and commit this fix. Don't forget commenting the
quilt patch so that we later remember whether it's worth being
submitted upstream (it probably is anyway....as it improves logging)
Information forwarded to debian-bugs-dist@lists.debian.org, Shadow package maintainers <pkg-shadow-devel@lists.alioth.debian.org>, Alexander Gattin <arg@online.com.ua>: Bug#332198; Package login.
(full text, mbox, link).
Acknowledgement sent to Alexander Gattin <xrgtn@yandex.ru>:
Extra info received and forwarded to list. Copy sent to Shadow package maintainers <pkg-shadow-devel@lists.alioth.debian.org>, Alexander Gattin <arg@online.com.ua>.
(full text, mbox, link).
Subject: Re: Bug#332198: [Pkg-shadow-devel] Bug#332198: Status of this bug
Date: Sat, 7 Jan 2006 21:37:39 +0200
Hi!
On Sat, Jan 07, 2006 at 09:46:13AM +0100, Christian Perrier wrote:
> So, Alex, please go and commit this fix. Don't forget commenting the
> quilt patch so that we later remember whether it's worth being
> submitted upstream (it probably is anyway....as it improves logging)
I think it's not worth propagating upstream right now,
as reason of bug #332198 is not yet discovered and
generally it's better to commit solution instead (i.e.
something with magic "Closes: #332198" stanza %)).
> Accepted:
> login_4.0.14-2_i386.deb
> to pool/main/s/shadow/login_4.0.14-2_i386.deb
> passwd_4.0.14-2_i386.deb
> to pool/main/s/shadow/passwd_4.0.14-2_i386.deb
> shadow_4.0.14-2.diff.gz
> to pool/main/s/shadow/shadow_4.0.14-2.diff.gz
> shadow_4.0.14-2.dsc
> to pool/main/s/shadow/shadow_4.0.14-2.dsc
oops, I wasn't in time :-/ and missed -2 release...
Sorry, Marc.
--
WBR,
xrgtn
Information forwarded to debian-bugs-dist@lists.debian.org, Shadow package maintainers <pkg-shadow-devel@lists.alioth.debian.org>, Alexander Gattin <arg@online.com.ua>: Bug#332198; Package login.
(full text, mbox, link).
Acknowledgement sent to Alexander Gattin <xrgtn@yandex.ru>:
Extra info received and forwarded to list. Copy sent to Shadow package maintainers <pkg-shadow-devel@lists.alioth.debian.org>, Alexander Gattin <arg@online.com.ua>.
(full text, mbox, link).
Subject: Re: Bug#332198: [Pkg-shadow-devel] Bug#332198: Status of this bug
Date: Sun, 8 Jan 2006 00:11:41 +0200
Forgot to say that I have committed the patch. Probably
I'll improve it further, but it's quite usable right
now.
Information forwarded to debian-bugs-dist@lists.debian.org, Shadow package maintainers <pkg-shadow-devel@lists.alioth.debian.org>, Alexander Gattin <arg@online.com.ua>: Bug#332198; Package login.
(full text, mbox, link).
Acknowledgement sent to Alexander Gattin <xrgtn@yandex.ru>:
Extra info received and forwarded to list. Copy sent to Shadow package maintainers <pkg-shadow-devel@lists.alioth.debian.org>, Alexander Gattin <arg@online.com.ua>.
(full text, mbox, link).
To: 332198@bugs.debian.org, 332198-submitter@bugs.debian.org
Cc: Marc Lehmann <schmorp@schmorp.de>
Subject: Re: Bug#332198: [Pkg-shadow-devel] Bug#332198: Status of this bug
Date: Sat, 21 Jan 2006 00:35:47 +0200
Hi!
On Sun, Jan 08, 2006 at 12:11:41AM +0200, Alexander Gattin wrote:
> Forgot to say that I have committed the patch. Probably
> I'll improve it further, but it's quite usable right
> now.
Marc, last shadow release (1:4.0.14-3) includes this
patch. It should give us more clue about what really
happens.
The patch adds SYSLOG statements, most interesting is:
SYSLOG ((LOG_WARN, "`%s'.st_rdev(%u,%u) != stdin.st_rdev(%u,%u)\n",
tty, major(by_name.st_rdev), minor(by_name.st_rdev),
major(by_fd.st_rdev), minor(by_fd.st_rdev)));
Thus you'll be able to see what sort of device is
login's stdin and its record in utmp...
--
WBR,
xrgtn
Message sent on to Marc Lehmann <debian-reportbug@plan9.de>:
Bug#332198.
(full text, mbox, link).
Information forwarded to debian-bugs-dist@lists.debian.org, Shadow package maintainers <pkg-shadow-devel@lists.alioth.debian.org>, Alexander Gattin <arg@online.com.ua>: Bug#332198; Package login.
(full text, mbox, link).
Acknowledgement sent to Marc Lehmann <schmorp@schmorp.de>:
Extra info received and forwarded to list. Copy sent to Shadow package maintainers <pkg-shadow-devel@lists.alioth.debian.org>, Alexander Gattin <arg@online.com.ua>.
(full text, mbox, link).
Subject: Re: Bug#332198: [Pkg-shadow-devel] Bug#332198: Status of this bug
Date: Sat, 21 Jan 2006 18:59:09 +0100
On Sat, Jan 21, 2006 at 12:35:47AM +0200, Alexander Gattin <xrgtn@yandex.ru> wrote:
> Hi!
>
> On Sun, Jan 08, 2006 at 12:11:41AM +0200, Alexander Gattin wrote:
> > Forgot to say that I have committed the patch. Probably
> > I'll improve it further, but it's quite usable right
> > now.
>
> Marc, last shadow release (1:4.0.14-3) includes this
> patch. It should give us more clue about what really
> happens.
I installed them and will have a look in the future. Thanks!
--
The choice of a
-----==- _GNU_
----==-- _ generation Marc Lehmann
---==---(_)__ __ ____ __ pcg@goof.com
--==---/ / _ \/ // /\ \/ / http://schmorp.de/
-=====/_/_//_/\_,_/ /_/\_\ XX11-RIPE
Message sent on to Marc Lehmann <debian-reportbug@plan9.de>:
Bug#332198.
(full text, mbox, link).
Information forwarded to debian-bugs-dist@lists.debian.org, Shadow package maintainers <pkg-shadow-devel@lists.alioth.debian.org>, Alexander Gattin <arg@online.com.ua>: Bug#332198; Package login.
(full text, mbox, link).
Acknowledgement sent to Christian Perrier <bubulle@debian.org>:
Extra info received and forwarded to list. Copy sent to Shadow package maintainers <pkg-shadow-devel@lists.alioth.debian.org>, Alexander Gattin <arg@online.com.ua>.
(full text, mbox, link).
To: Marc Lehmann <schmorp@schmorp.de>, 332198@bugs.debian.org
Subject: Re: Bug#332198: [Pkg-shadow-devel] Bug#332198: Status of this bug
Date: Tue, 7 Feb 2006 18:43:29 +0100
> > > Forgot to say that I have committed the patch. Probably
> > > I'll improve it further, but it's quite usable right
> > > now.
> >
> > Marc, last shadow release (1:4.0.14-3) includes this
> > patch. It should give us more clue about what really
> > happens.
>
> I installed them and will have a look in the future. Thanks!
Marc,
Have you again been hit by this bug?
Information forwarded to debian-bugs-dist@lists.debian.org, Shadow package maintainers <pkg-shadow-devel@lists.alioth.debian.org>, Alexander Gattin <arg@online.com.ua>: Bug#332198; Package login.
(full text, mbox, link).
Acknowledgement sent to Marc Lehmann <schmorp@schmorp.de>:
Extra info received and forwarded to list. Copy sent to Shadow package maintainers <pkg-shadow-devel@lists.alioth.debian.org>, Alexander Gattin <arg@online.com.ua>.
(full text, mbox, link).
Subject: Re: Bug#332198: [Pkg-shadow-devel] Bug#332198: Status of this bug
Date: Thu, 9 Feb 2006 06:55:36 +0100
On Tue, Feb 07, 2006 at 06:43:29PM +0100, Christian Perrier <bubulle@debian.org> wrote:
> > > patch. It should give us more clue about what really
> > > happens.
> >
> > I installed them and will have a look in the future. Thanks!
>
>
> Marc,
>
> Have you again been hit by this bug?
Unfotunately(?) not (it can be weeks or months in between, and then I
cna get a lot of failure sin a row). However, I can't seem to get much
mor elogging, either, but I assume this is because it only logs unusual
things (failures :)?
--
The choice of a
-----==- _GNU_
----==-- _ generation Marc Lehmann
---==---(_)__ __ ____ __ pcg@goof.com
--==---/ / _ \/ // /\ \/ / http://schmorp.de/
-=====/_/_//_/\_,_/ /_/\_\ XX11-RIPE
Information forwarded to debian-bugs-dist@lists.debian.org, Shadow package maintainers <pkg-shadow-devel@lists.alioth.debian.org>, Alexander Gattin <arg@online.com.ua>: Bug#332198; Package login.
(full text, mbox, link).
Acknowledgement sent to Marc Lehmann <schmorp@schmorp.de>:
Extra info received and forwarded to list. Copy sent to Shadow package maintainers <pkg-shadow-devel@lists.alioth.debian.org>, Alexander Gattin <arg@online.com.ua>.
(full text, mbox, link).
Subject: Re: Bug#332198: [Pkg-shadow-devel] Bug#332198: Status of this bug
Date: Sat, 11 Feb 2006 00:11:07 +0100
On Tue, Feb 07, 2006 at 06:43:29PM +0100, Christian Perrier <bubulle@debian.org> wrote:
>
> > I installed them and will have a look in the future. Thanks!
>
> Marc,
>
> Have you again been hit by this bug?
Just now after a long time of it working:
Feb 11 00:08:15 cerebro pam_rhosts_auth[511]: allowed to root@fuji as root
Feb 11 00:08:16 cerebro login[512]: (pam_unix) session opened for user root by (uid=0)
Feb 11 00:08:16 cerebro login[512]: `/dev/pts/2'.st_rdev(136,2) != stdin.st_rdev(136,1)
Feb 11 00:08:16 cerebro login[512]: unable to determine TTY name, got /dev/pts/2
--
The choice of a
-----==- _GNU_
----==-- _ generation Marc Lehmann
---==---(_)__ __ ____ __ pcg@goof.com
--==---/ / _ \/ // /\ \/ / http://schmorp.de/
-=====/_/_//_/\_,_/ /_/\_\ XX11-RIPE
Information forwarded to debian-bugs-dist@lists.debian.org, Shadow package maintainers <pkg-shadow-devel@lists.alioth.debian.org>, Alexander Gattin <arg@online.com.ua>: Bug#332198; Package login.
(full text, mbox, link).
Acknowledgement sent to Christian Perrier <bubulle@debian.org>:
Extra info received and forwarded to list. Copy sent to Shadow package maintainers <pkg-shadow-devel@lists.alioth.debian.org>, Alexander Gattin <arg@online.com.ua>.
(full text, mbox, link).
Alex, in #332198, the bug submitter reported a failure on Feb 11th
with some extra output because of the patch you added, that allows mor
elogging to occur.
Could this be investigated again?
--
Information forwarded to debian-bugs-dist@lists.debian.org, Shadow package maintainers <pkg-shadow-devel@lists.alioth.debian.org>, Alexander Gattin <arg@online.com.ua>: Bug#332198; Package login.
(full text, mbox, link).
Acknowledgement sent to Alexander Gattin <xrgtn@yandex.ru>:
Extra info received and forwarded to list. Copy sent to Shadow package maintainers <pkg-shadow-devel@lists.alioth.debian.org>, Alexander Gattin <arg@online.com.ua>.
(full text, mbox, link).
Hi!
On Wed, May 10, 2006 at 10:13:40AM +0200, Christian Perrier wrote:
> Could this be investigated again?
IMHO the bug is related to utmp corruption.
Right now I'm not quite ready to debug the issue deeper
as I don't know how exactly is the utmp is used in
Unices.
I'll try to come up with some idea until June.
--
WBR,
xrgtn
Reply sent to Christian Perrier <bubulle@debian.org>:
You have taken responsibility.
(full text, mbox, link).
Notification sent to Marc Lehmann <debian-reportbug@plan9.de>:
Bug acknowledged by developer.
(full text, mbox, link).
This bug is impossible to reproduce and it is more than 1 year since
we got news about it.
Unless the issue ir really affecting you *now*, I suggest not
reopening it.
--
Debbugs is free software and licensed under the terms of the GNU General
Public License version 2. The current version can be obtained
from https://bugs.debian.org/debbugs-source/.