Bug 140297 - Remote logins from terminals trash utmp entries
Remote logins from terminals trash utmp entries
Status: CLOSED UPSTREAM
Product: Fedora
Classification: Fedora
Component: gdm (Show other bugs)
3
i686 Linux
medium Severity low
: ---
: ---
Assigned To: Ray Strode [halfline]
http://www.pastebin.com/122175
:
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2004-11-22 00:05 EST by Sean Bruno
Modified: 2007-11-30 17:10 EST (History)
2 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2006-10-31 00:04:31 EST
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:


Attachments (Terms of Use)
Patches session scripts of gdm (4.42 KB, application/octet-stream)
2005-05-12 15:45 EDT, Jose L. Beltrami
no flags Details

  None (edit)
Description Sean Bruno 2004-11-22 00:05:16 EST
From Bugzilla Helper:
User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.7.5)
Gecko/20041111 Firefox/1.0

Description of problem:
I am experiencing a strange user login reporting issue and it seems to
be way above my head.  

Let me describe the system first and then explain the problem.

I have a dual-processor server(DELL PE 2650 in case you care) that is
acting as an NFS/TFTP/DHCP/GDM server for a couple of hundred NCD Tek
Terminals(Multiple Models and types).  The users login to the
terminals so that they can run a Java call center application and take
phone calls.  

Initially, the terminals came up on the same IP network as the server
itself and all was good.

Recently, this design was changed slightly.  Now there is a 2nd IP
address assigned to the same physical adapter on the server.  So there
is a eth0 and an eth0:0 ... This IP address is on a seperate network
specifically assigned for these terminals and is non-routeable.

The issue I am seeing is a strange behaviour to wtmp/utmp wherein the
users don't show up as being logged in via "w" or "who"

The only user to show up, is the last user to login.  Also, normal
user logins who get desktops and other terminal applications that are
different from the operator login show up just fine as well.  Here is
an example of a "good" server's output from "w":

14:10:08  up 105 days, 14:29, 11 users,  load average: 0.08, 0.02, 0.01
USER     TTY      FROM              LOGIN@   IDLE   JCPU   PCPU  WHAT
eda01    tek01:0  tek01            Thu 2pm  0.00s 47:15   3.49s 
/usr/java/j2sdk1.5.0/bin/java
eda31    tek31:0  tek31            12:02pm  0.00s 47:15   3.40s 
/usr/java/j2sdk1.5.0/bin/java
eda05    tek05:0  tek05             7:42am  0.00s 47:15   3.30s 
/usr/java/j2sdk1.5.0/bin/java
eda04    tek04:0  tek04            12Nov04  0.00s 47:15   2.12s 
/usr/java/j2sdk1.5.0/bin/java
sean     pts/4    oscar            2:09pm  0.00s  0.05s  0.01s  w
eda21    tek21:0  tek21            Sat 4pm  0.00s 47:15   3.18s 
/usr/java/j2sdk1.5.0/bin/java
eda12    csr-12-p csr-12-pdx       Fri10pm  0.00s 47:15   3.51s 
/usr/java/j2sdk1.5.0/bin/java

As you can see, there are muliple users of the username "edaXX." 
These are the operators who are logged in and using the system.  

And here is the output of "w" from a "bad" machine, "bad" being a
server that has the 2nd IP address assigned to the same physical
network adaptor:

17:13:43  up 11 days, 17:01, 13 users,  load average: 0.22, 0.26, 0.27
USER     TTY      FROM              LOGIN@   IDLE   JCPU   PCPU  WHAT
eda4181  tek4181. tek4181          4:54pm  0.00s  2:05m  4.15s 
/usr/java/j2sdk1.5.0/bin/java
rtcdr2   pts/0    -                Tue11am  3:40m  3.24s  3.24s  ssh
-t cdruser@192.168.33.3 /metr
ssteele  pts/2    -                Sat10am 30:39m 34.86s 34.86s  acd
rtcdr2   pts/4    -                Tue11am  5days 11.71s 11.71s  acd
nanc     pts/6    -                Mon 5pm  3days 10.88s 10.88s  ssh
-t cdruser@192.168.33.3 /metr
sean     pts/3    oscar            5:13pm  0.00s  0.05s  0.03s  w
ade      pts/9    small            Thu11pm  2days  0.03s  0.03s  -bash
rtcdr2   pts/5    -                12:26pm  4:47m  0.07s  0.07s  ssh
-t cdruser@192.168.33.3 /metr
jyang    pts/1    apollo           Sat 3pm 25:30m  0.25s  0.25s  -bash
ssteele  pts/7    -                Sat10am  2:27m  3.69s  3.69s  ssh
-t cdruser@192.168.33.3
rtcdr2   pts/11   -                Sat 4pm 24:42m 28.70s 28.70s  acd
cotti    pts/12   quasi            Fri 3pm  2days  0.02s  0.02s  -bash
rtcdr2   pts/13   -                Sat 4pm 21:28m  5.49s  5.49s  ssh
-t cdruser@192.168.33.3 /metr

Here there is only one "edaXX" user logged in and if another operator
logs in, the user "eda4181" will dissappear from the "w" output and be
replaced by a different operator.

I am very confused here why the IP addressing scheme of the machine
would have this type of effect on utmp/wtmp login reporting...Any
clues folks?

UPDATE:  Well, even a more confusing piece of information...It appears
that the "last" command functions exactly as it should, i.e. showing
proper login/logout history...So where does this point to?

UPDATE2:  After some discussions on IRC, I need to clarify the fact
that there are TWO seperate networks configured on the same physical
network adapter.  This is the key to the problem.  If I configure two
different physical network adapters, the issue goes away.  If I run
the entire thing off of one IP/Network adapter, the issue goes away.

Version-Release number of selected component (if applicable):
Unknown

How reproducible:
Always

Steps to Reproduce:
1.  Configure a system to serve up terminal services to NCD type Tek
terms.
2.  Configure a secondary network interface on the primary(and only)
network adapter.
3.   Log into two different terminals and check the output of "w"
    

Actual Results:  The last person to login successfully will be the
only user to show up in the output of "w"

Expected Results:  All logins reported correctly

Additional info:

Not really a "high" priority issue here folks, it just caught me
off-guard the other day when I was checking my operator logins on some
machines and only one operator showed as logged in.
Comment 1 Sean Bruno 2004-11-24 01:32:05 EST
Update from today, you should be able to do this with any two machines
running an X server.  Just have them connect to the login manager(gdm
in my tests) on the third, server macine.
Comment 2 Sean Bruno 2005-03-28 12:39:23 EST
We resolved this issue by ensuring that the hostname of the terminals was less
than 16 characters in length.

There appears to be something "wonky" occuring when the hostname is a full name
like "tek4066.metro1.com" instead of "tek4066"

If you want to close this issue, go ahead.
Comment 3 Ray Strode [halfline] 2005-05-11 17:36:58 EDT
Hi,

This bug is being closed because it has been in the NEEDINFO state for a long
time now.  Feel free to reopen the bug report if the problem still happens for
you and you can provide any information that was requested.
Comment 4 Jose L. Beltrami 2005-05-12 15:45:51 EDT
Created attachment 114311 [details]
Patches session scripts of gdm
Comment 5 Jose L. Beltrami 2005-05-12 15:47:20 EDT
(In reply to comment #3)
> Hi,
> 
> This bug is being closed because it has been in the NEEDINFO state for a long
> time now.  Feel free to reopen the bug report if the problem still happens for
> you and you can provide any information that was requested.

Hi Ray,
Sean was right in the fact that the problem is caused by a DISPLAY name of more
than 16 chars.
I traced this problem down to the sessreg program call in the
/etc/X11/gdm/PreSession/Default and /etc/X11/gdm/PostSession/Default scripts.
Perhaps the more elegant solution were to patch the sessreg program, but I
builded an rpm (attached in srpm format) that patches those scripts. 
Simply put, it sustitutes the "... -l \"$DISPLAY\" ..." command line parameter
in the invocation of sessreg, by "... -l \"`echo $DISPLAY | cut -d. -f1`\" ..."
Wishing that this were useful to bring a solution to this problem, thank you for
reopen this bug. 
Best regards,

     José Luis
Comment 6 Matthew Miller 2006-07-10 19:07:29 EDT
Fedora Core 3 is now maintained by the Fedora Legacy project for security
updates only. If this problem is a security issue, please reopen and
reassign to the Fedora Legacy product. If it is not a security issue and
hasn't been resolved in the current FC5 updates or in the FC6 test
release, reopen and change the version to match.

Thank you!
Comment 7 Sean Bruno 2006-09-16 16:25:41 EDT
I no longer have anyway to test this.

I'm not sure why this is in a NEEDINFO state as I was pretty clear where the
specific error is and I don't see any requests for Information in any of the
comments.

In addition, I see a 'me too' comment so I'm not sure that anyone has actually
fixed this.

And finally, since it's under FC3 and that is long since gone, my last comment
would be to say that it probably impacts your RHEL4 customers and should be
looked into.

Comment 8 John Thacker 2006-10-31 00:04:31 EST
Well, Comment #6 put it in NEEDINFO attempting to ask whether or not the issue
still shows up in a fully supported release of Fedora Core (FC5 or FC6).  There
are hundreds of open bugs originally filed against FC3, which is no longer
supported except for security updates, that have no comment indicating whether
they are still present in FC5 or FC6.  Many have been fixed, whether upstream or
not, without the bugs getting closed.

It takes a rather long time to go through every bug individually and verify it,
so some people, like Matt, go through and make mass updates to the FC3 bugs (and
other old bugs) asking people to verify if the issue still exists.  I'm sorry
that "If it is not a security issue and hasn't been resolved in the current FC5
updates or in the FC6 test release" was not an obvious enough request for
information.

In the case of this bug, it appears fixed on FC6/  At least, there does not
appear to be a sessreg call in /etc/gdm/PostSession/Default and
/etc/gdm/PreSession/Default (though the comments still refer to it), nor is
there a reference to $DISPLAY in there.  I'm not sure *when* it was fixed, though.

Note You need to log in before you can comment on or make changes to this bug.