Path: utzoo!utgpu!cunews!bnrgate!brtph3!brchh104!date '+%m/%d/%y %H:%M:%S'brchs1!bnr.ca!rice.edu!sun-spots-request
From: pfalstad@phoenix.princeton.edu (Paul John Falstad)
Newsgroups: comp.sys.sun
Subject: Possible bug in 4.1 in.comsat
Keywords: SunOS
Message-ID: <447@brchh104.bnr.ca>
Date: 26 Nov 90 17:30:00 GMT
Sender: news@brchh104.bnr.ca
Organization: Sun-Spots
Lines: 14
Approved: Sun-Spots@rice.edu
X-Original-Date: 8 Nov 90 05:05:31 GMT
X-Sun-Spots-Digest: Volume 9, Issue 376, message 9
X-Note: Submissions: sun-spots@rice.edu, Admin: sun-spots-request@rice.edu

Has anyone heard about a bug in in.comsat in SunOS 4.1?  I'm not getting
biffed on my system.  I took a look at the binaries, and figured out that
comsat calls getpwnam() with a userid it gets from the ut_name field in
utmp.  Of course, ut_name is an 8 character buffer, so the string isn't
null terminated if the person's username is 8 characters (like mine is).
The name runs into the ut_host field, so the getpwnam fails, and comsat
segfaults.  I checked this by exec'ing /bin/login (which clears the
ut_host field), and mailing myself some things.  Biff worked fine then,
because ut_host is set to all nulls, which provides the null terminator
for the user name.

Anyone heard about this?  Or is it a bug in my head?

Paul Falstad, pfalstad@phoenix.princeton.edu PLink:HYPNOS GEnie:P.FALSTAD