OS: SuSE 9.0 This is a new FTP installation updated via YOU. During the install, one non-root user was created and used successfully for about a week. First sign of trouble: we couldn't login with error indicating an incorrect password. AS root we reset the password and can now login on a character screen but when logging in under KDE, receive the following error: There was an error setting up inter-process communications with KDE. The message returned by the system was: Could not read network connection list /home/<user>/.DCOPserver_HBADMIN_0 Please check that the dcopserver program is running. A quick check of running processes shows no such process. The KDE login fails and returns to a login screen. All other users can login just fine. Further, we tried removing this use and his home directory along with all files/subdirectories but were unable to even list the following dirctories: cannot access /home/<user>/.qt (permission denied) cannot access /home/<user>/.kde (permission denied) cannot access /home/<user>/.wine (permission denied) cannot access /home/<user>/Desktop (permission denied) even as root. Could this system have been hacked or compromised in some way? (How would I go about checking this?) If so, what should we do about it? (I did enable SuSEfirewall2 closing all ports to the outside world.) Thank you, Lucky Leavell
Lucky Leavell wrote:
OS: SuSE 9.0
This is a new FTP installation updated via YOU. During the install, one non-root user was created and used successfully for about a week. First sign of trouble: we couldn't login with error indicating an incorrect password. AS root we reset the password and can now login on a character screen but when logging in under KDE, receive the following error:
There was an error setting up inter-process communications with KDE. The message returned by the system was:
Could not read network connection list /home/<user>/.DCOPserver_HBADMIN_0
Please check that the dcopserver program is running.
A quick check of running processes shows no such process.
The KDE login fails and returns to a login screen. All other users can login just fine.
Further, we tried removing this use and his home directory along with all files/subdirectories but were unable to even list the following dirctories:
cannot access /home/<user>/.qt (permission denied) cannot access /home/<user>/.kde (permission denied) cannot access /home/<user>/.wine (permission denied) cannot access /home/<user>/Desktop (permission denied)
even as root.
Could this system have been hacked or compromised in some way? (How would I go about checking this?) If so, what should we do about it?
(I did enable SuSEfirewall2 closing all ports to the outside world.)
Thank you, Lucky Leavell
I'm not sure if this is related of not but maybe someone else can use this information to create a better picture. I use rsync nightly (cron job) to backup my entire home directory into a DVDRAM drive. ($HOME is part of /dev/hda2, DVDRAM drive = /dev/hdb [whole disk!] ) Last night, I got funny messages that indicated that the backup failed. When I tried to rsync manually, I got messages that showed that some of my subdirectories could not be read. I cdeed to those directories and performed an "ls -ltra". I got error messages similar to the ones you describe (.DCOPserveretc., cannot access .kdewhatever, etc etc) I could not remove the subdirectories manually even after chmod and becoming root. I booted (after trying a couple of things which I forget) off the rescue disk to run fsck on my hard disk where I keep my home directory. fsck showed no errors. I rebooted normally and ran rsync again, same problems. (DVDRAM drive is mounted as per /etc/fstab) Could not read some of my own subdirectories. I tried to fsck the dvdram drive (/dev/hdb). This failed. In other words, pass after pass showed the same errors. I reformatted the dvdram drive. No problems. I ran rsync. No problems. The system is now happy. So, what does it mean? I haven't a clue. I can conjecture endlessly though. One of them: Something wrong with the DVDRAM caused the /dev/hdb driver to bugger up the OS which manifests itself as problems reading the /dev/hda2 partition. I accept any other possible explanation. My humility knows no boundaries. Cheers
The Wednesday 2004-04-28 at 09:53 -0400, Lucky Leavell wrote:
Further, we tried removing this use and his home directory along with all files/subdirectories but were unable to even list the following dirctories:
cannot access /home/<user>/.qt (permission denied) cannot access /home/<user>/.kde (permission denied) cannot access /home/<user>/.wine (permission denied) cannot access /home/<user>/Desktop (permission denied)
even as root.
My guess is that you have a reiserfs partition, and that it is corrupted. Reboot form the CD, enter rescue system, and run "reiserfsck" on your partition. Follow its advices. You are not the first one with similar symptoms. -- Cheers, Carlos Robinson
On Thu, 29 Apr 2004, Carlos E. R. wrote:
My guess is that you have a reiserfs partition, and that it is corrupted. Reboot form the CD, enter rescue system, and run "reiserfsck" on your partition. Follow its advices.
Yes it is the [default] reiserfs. I have done quite a bit of research on Linux FSes since posting this and wish there were a clear choice. I guess all I can do is try each (particularly xfs and jfs) and see which gives the most reliable FS. I understand the need to boot from a rescue CD/floppy to repair a FS but can, for example, reiserfsck --check be run on a running system or does even that require using the rescue system? (I read the man page on reiserfsck and could not find the answer.) Thank you, Lucky Leavell
On Monday 03 May 2004 16:35, Lucky Leavell wrote:
can, for example, reiserfsck --check be run on a running system or does even that require using the rescue system?
~ i believe file-system checks can only be run on un-mounted file-systems. -- best wishes ____________ sent on Linux ____________
The Monday 2004-05-03 at 12:35 -0400, Lucky Leavell wrote:
I understand the need to boot from a rescue CD/floppy to repair a FS but can, for example, reiserfsck --check be run on a running system or does even that require using the rescue system? (I read the man page on reiserfsck and could not find the answer.)
It will do some checking, but no repairs, or almost not so. In your case, use the rescue CD: as I said, you are not the first one with that or a similar problem (a. denied). -- Cheers, Carlos Robinson
participants (4)
-
Carlos E. R. -
expatriate -
Lucky Leavell -
pinto