[cobalt-users] RE: [Qube2]Wierd Login prompt (I have no name!@machine) [FIXED]

["Colin J. Raven" <cjraven@xxxxxxxxxxx>]

On Wednesday 18 April 2001, shimi responded thusly:
> On Tue, 17 Apr 2001, Colin J. Raven wrote:
>
> > Hi Gang!!
> > A strange and unusual event happened on a Qube2. The shell
> login prompt
> > has changed from [user@machine]$
> > to
> > [I have no name!@machine username]$
> >
> >
> > doing a "whoami" from the prompt produces the following:
> > [I have no name!@machine username]$ whoami
> > whoami: cannot find username for UID 112
> >
> > When the user attempts to start pine he also sees the following:
> > [I have no name!@machine username]$ pine
> > Who are you? (Unable to look up login name)
> >
> > The user can login succcessfully, can su to root
> successfully (this is a
> > trusted user) but keeps getting the message above. Nothing
> seems broken.
> > In /etc/profile and all .bash_profile files the shell
> prompt PS1 string
> > has been commented out, but of course this has no effect.
> >
> >
> > Has anyone ever encountered this behavior before? A search of the
> > archives drew a *complete* blank on this one.
> >
>
> Hehe, no wonder. This doesn't happen just like that. It once
> happend to
> me.. before shadow passwords appeared on redhat, I didn't
> want any local
> user (or via that FTP bug that has been back then, CWD ~/root or
> something) to grab a copy of /etc/passwd and start brute
> forcing to crack
> a password of a user on the system.
> So I made /etc/passwd readable only by root (basically
> removed read access
> from group and other) - the result was what you just
> describe. If you're
> wondering why it's possible to login at all, that's because
> the program
> which accepts logins is ran from root.
>
> unless you didn't touch /etc/passwd permissions - someone
> else did - and
> you should be VERY worried, because that "someone" has root access to
> your machine...
>
That's it. The perms on /etc/passwd were at 600 when I checked it.
Ratcheting up to 640 didn't change the behaviour
Bumping up to 644 fixed it.

Here's the wierd (weird?) thing. The box in question has *no* internet
access whatsoever. It's an intranet mail and specification-document
server only and in a building without an internet connection (there's a
deliberate reason for this, but it's a long story). One other user has
access to the shell (he adds users and takes care of some basic
housekeeping) He doesn't know enough to mess with /etc/passwd perms. The
likelihood of the box being compromised therefore, is as close to zero
as you can get in practical terms. I checked the local admin's
.bash_history and he hadn't been anywhere near the file. Root's
.bash_history also showed no activity around the file. Earlier in the
day I rebooted the machine from a command prompt, and after the reboot
the command prompt was munged up. I cannot understand how rebooting
could change the perms on that file, but sure as hell, the odd behaviour
showed up immediately following reboot.

Anyway, it's fixed. Thanks shimi!!!!!
Regards,
-Colin
--
Colin J. Raven