I’ve just suffered a weird incident unlike anything I’ve seen before and I’m wondering if anyone has any ideas on what might have happened.
I’m running Suse 10.3 64bit with KDE. I was doing a bit of programming this afternoon in my user account and had screens full of clutter, so I locked my session while I had my tea. Later, my wife came complaining that she couldn’t log into her user account. It kept saying her password was invalid.
I tried, and sure enough the password wasn’t recognised. I tried to re-activate my session and the same thing happened. Then I noticed that it said “session locked by root”.
Well I certainly wasn’t logged in as root, but I entered the root password and my session came back just as it was before. Well, nearly…
I appeared to have turned into root. All my files were owned by root and whoami gave “root”. However $USER and $HOME were still me. This happened in both new and existing command line sessions. Also, other users seemed to have ceased to exist because “su user” said “user does not exist” whatever user I chose and just using “su” just hung. If I referenced ~user I got “file does not exist”. The other thing I noticed was that the groups command gave an error (something like “can’t find a value for group 33”).
I didn’t actually appear to have any root privileges, however.
Not knowing what else to do, I shut the machine down and re-booted (it had only been up a few hours). When I logged back in, everything seemed normal. Thankfully, my files were now all owned by me, so there didn’t seem to be any damage done.
But weird, no?
I guess some part of the system must have hung or died, but what and why? The system has been stable for a year or so but there have been the usual online updates, of course. Nothing obvious in the logs. Anyone any ideas?
> I didn’t actually appear to have any root privileges, however.
>
> Not knowing what else to do, I shut the machine down and re-booted (it
> had only been up a few hours). When I logged back in, everything
> seemed normal. Thankfully, my files were now all owned by me, so there
> didn’t seem to be any damage done.
>
> But weird, no?
>
> I guess some part of the system must have hung or died, but what and
> why? The system has been stable for a year or so but there have been
> the usual online updates, of course. Nothing obvious in the logs.
> Anyone any ideas?
>
>
There may be a perfectly simple explanation for this ( I have never come
across it before though ) but if it was me I would run a rootkit checker
search with yast for:
chkrootkit
And give your system a scan.
Might not be anything so bad though and just a one off glitch
Good idea. A rootkit did flash through my mind at the time but I forgot about it amongst the relief of getting things back to normal.
I’ve done a quick run of chkrootkit and it didn’t find anything, although one of the test programs did crash. I don’t think that’s necessarily suspicious (probably just a bug) as it was only reading the utmp file. I’ll do a proper check from a rescue system when I have a little more time.
If I had to guess, I’d say the original problem would be consistent with the death of whatever translated user IDs into usernames. If that was always producing “root” as the username, that would probably explain it. I suppose that might be a function that a rootkit would try to subvert, but as I say, no actual evidence of a rootkit as yet. I’ll keep looking, though.
BTW I’m not a fan of the “it’s a one-off” explanation. That I expect on Windows, not Linux.
The nscd(8) - name service cache daemon is not renowned for being 100% bug free, I wonder if entries for your UID got replaced by that for root, or if it simply failed and fallback is root user info.
You say you were programming! I had similar effects caused when somebody ran something as root with an improper ENVIRONMENT which then made /, /etc non-searchable by non-root users. It took me a while to debug and find, because the “culprit” denied having run anything that could affect the system (developers debugging scripts as root is SNAFU, as they are overly optomistic). If you boot up machine, and leave it, perhaps the daily script gets run and fixes up the permissions. But I doubt this explanation as nscd ought to have the entries in cache.