Best of Tech Support

Our experts answer your technical questions.
Best of Technical Support

Permissions Change on /etc

I am experiencing random permission 600 applied to /etc. Sometimes I can go a day without being struck, and sometimes only minutes later, after doing chmod 755 /etc, it's back to 600. I thought this might be some protection feature in the kernel to protect against bad memory or mass storage. I have changed out memory, leaving only one stick fully qualified by my motherboard maker, but to no avail. I can't play with the disks right now. I reduced the number of processes to those listed in the attached file. Is this a normal feature due to marginal hardware, a misinstalled application or is my system hacked?

—Stan Katz, stan@cloud9.net

Hardware issues will (almost) never cause filesystem changes in this manner and certainly not in such a consistent manner. It's time to look for applications (possibly malignant) that may be causing the problem. You need to examine your other log files—something might be a hint there. You only included messages through the system boot, nothing from its operation. Start by looking in all crontab files, tracing out processes that are run from it. Also compare the system dæmon binaries you are running, as well as other regularly used tools, against those on your installation media to verify that they have not been replaced with a Trojan horse. Finally, check for applications that are setuid root, since those are a sure tip-off that you have been compromised. However, it's unusual for a Trojan horse to restrict the permissions on a directory. Without access to the system, its log files and the ability to examine the files installed, we cannot further analyze the problem.

—Chad Robinson, crobinson@rfgonline.com

You almost certainly have a cron job that is resetting the permissions, or worse, a cracker kernel module that is messing around with your system. You should try chmod 755 /etc; chattr -i /etc to make /etc immutable, which hopefully will help make whatever program is resetting the permissions fail (for a cron job, you may even get an error by mail). Typing rgrep -r chmod /etc /var/spool/cron may also give you a clue as to what is changing the permissions.

—Marc Merlin, marc_bts@valinux.com

This is not a feature. Sounds like a Trojan or misinstalled program. This is a difficult problem to find. Try to do an lsof /etc to see if any program is currently holding the directory open. This may give you a clue. Next, shut down various services/programs until you find the offending program. It might be easier to re-install your version of Linux from scratch.

—Christopher Wingert, cwingert@qualcomm.com

I Do Believe in /dev/st0!

I can't access my tape! Running dmesg shows:

scsi0 : Adaptec AHA274x/284x/294x
        (EISA/VLB/PCI-Fast SCSI) 5.1.33/3.2.4
       <Adaptec AHA-294X Ultra SCSI host adapter>
scsi : 1 host.
  Vendor: ARCHIVE  Model: Python 28454-XXX  Rev: 4ASB
  Type:   Sequential-Access    ANSI SCSI revision: 02
  Vendor: FUJITSU   Model: M1606S-512       Rev: 6236
  Type:   Direct-Access        ANSI SCSI revision: 02
Detected scsi disk sda at scsi0, channel 0, id 3, lun 0
scsi : detected 2 SCSI generics 1 SCSI disk total.
(scsi0:0:3:0) Synchronous at 10.0 Mbyte/sec, offset 15.
SCSI device sda: hdwr sector= 512 bytes.
Sectors= 2131992 [1041 MB] [1.0GB]

I can access the SCSI disk but not the tape. Both eth0 and aic7xxx are on interrupt 9. I have SCSI tape support compiled in the kernel. This is all on a P133.

—Andy Prowse, azp80@amdahl.com

Normally, dmesg(8) should show a line referencing st0 as a device found in the summary, just below the entry about sda. See the example below from my own system:

Detected scsi tape st0 at scsi0, channel 0, id 6, lun 0

Your tape drive is being discovered as a “generic” device, but you cannot use mt(1) without the tape driver active. Check your kernel compilation options. Depending on your kernel version, this should be under “SCSI support” and named “SCSI tape support”.

—Chad Robinson, crobinson@rfgonline.com

Routing to ppp0

I installed Red Hat 7.2 with a network card and successfully connected to the Internet with a cable modem connection hosted on another machine in the network. Now I need to connect to a dialup account. The modem is correctly configured (I can log in successfully). But when I try to work with the dialup account, I am unable to connect to its mail server because my Linux box is using eth0 routes as the default routes. How do I change the routing tables to fix this? I already checked the box to make ppp0 the default connection, but that did not solve the problem.

—Kelvin Barnes, Kelvin.Barnes@att.net

You have a default route going to your Ethernet interface that is superseding the default route added by PPP. You can try route del -net default before bringing your PPP interface up, and then it should work. You also can use the Red Hat GUI to bring eth0 down and back up.

—Marc Merlin, marc_bts@valinux.com

______________________

Webinar
One Click, Universal Protection: Implementing Centralized Security Policies on Linux Systems

As Linux continues to play an ever increasing role in corporate data centers and institutions, ensuring the integrity and protection of these systems must be a priority. With 60% of the world's websites and an increasing share of organization's mission-critical workloads running on Linux, failing to stop malware and other advanced threats on Linux can increasingly impact an organization's reputation and bottom line.

Learn More

Sponsored by Bit9

Webinar
Linux Backup and Recovery Webinar

Most companies incorporate backup procedures for critical data, which can be restored quickly if a loss occurs. However, fewer companies are prepared for catastrophic system failures, in which they lose all data, the entire operating system, applications, settings, patches and more, reducing their system(s) to “bare metal.” After all, before data can be restored to a system, there must be a system to restore it to.

In this one hour webinar, learn how to enhance your existing backup strategies for better disaster recovery preparedness using Storix System Backup Administrator (SBAdmin), a highly flexible bare-metal recovery solution for UNIX and Linux systems.

Learn More

Sponsored by Storix