Quoting Bob Scofield (scofi...@omsoft.com): > I've got an infected Linux desktop and I don't have the technical > expertise to fix it.
So, I just wanted to explore the notion of 'infected' in general, concerning Linux computers. (In no way is this intended as a criticism of Bob.) It is frequently the case that users say their computers are infected / have malware when all they really know is that something bad is happening on their systems that ought not to happen -- something like a Web browser process immediately terminating upon startup. It's a small leap of logic, but certainly an understandable one. In my first, long post, trying to help advise Bob, I drew a key distinction between system-level problems and user-level ones, e.g., suggesting Bob see if additional user 'test' encountered the same symptom he did under his regular user. Each user has an individual set of configuration files in his/her homedir that, if they get messed up by... anything (user mishap, 'malware' processes the system gets tricked into running with regular user authority, damage caused by bugs in installed user software run with regular user authority, etc.)..., the user's software experience can get sabotaged _without_ there having been any damage to the system as a whole. And the reason that's a really key difference is that you as a non-privileged user deliberately are not wielding the ability to mess up, edit, add to, delete from, etc., files in any of the many trees that are _system_ trees. Which also means that even the most devilishly nasty malware imaginable, if you happened to run it as 'you' (run it with your user authority), can do only the damage that you, yourself, could have done. That is why, in a real sense, _provided_ you are not finding dumb ways to run Linux malware with elevated privilege, and provided it isn't left running for a long time to chip away at your system and find unfixed local security problems to 'escalate privilege' with, such Linux malware is precisely as big a danger to your system as you are, and as big a danger to your personal files as you are. (The corrolary to this is that the biggest danger by far to any Linux server is a sysadmin wielding root authority, something even scarier than a programmer clutching a screwdriver. ;-> ) And I actually need to 'fess up to a bit of tunnel vision I suffered in making the above-described distinction between system-level problems and user-level ones: I almost totally forgot -- but sort of added near the end -- that something like a critical RAM shortage in effect manifests as _both_ a system-level and user-level problem. But often I forget that new Linux 'desktop' users are seldom taught that just about the first things you need to do is: o Check memory using 'free' or similar. o Check disk space using 'df' or similar. o Check process list (using 'ps' or similar) looking for funny business. That is so ingrained in old-school Unix teaching that sometimes it's difficult to remember that newcomers may not think to do that, and almost certainly aren't familiar with the tools. Which is a pity. ...and, please note, Bob's problem immediately became obvious when he checked the third of those three basics. Rod's point that it _could_ have been a hardware problem was also an excellent one, but IMO one wants to look for the low-hanging fruit, first. _______________________________________________ vox-tech mailing list vox-tech@lists.lugod.org http://lists.lugod.org/mailman/listinfo/vox-tech