Solution to Permission denied to /etc/mtab

I was setting up a hypervisor for RHEV running a full RHEL6 install instead of RHEV-H, and I wanted to tune it for better hypervisorness.

So I thought, Hey! I'll install tuned, since I am all excited about tuned after viewing the slides from Mark Wagner's Achieving Top Network Performance (PDF) at the 2012 Red Hat Summit. I was particularly excited about slide 12 entitled "Teaser 3 - latency."

Not to mention that the tuned virtual-host profile is the recommended profile for RHEV hosts.

Anyway, I went ahead and installed tuned and applied the virtual-host profile:

# yum -y install tuned
...
# tuned-adm profile virtual-host
Switching to profile 'virtual-host'
Applying ktune sysctl settings:
/etc/ktune.d/tunedadm.conf: [ OK ]
Calling '/etc/ktune.d/tunedadm.sh start': can't rename /etc/mtab.tmp to /etc/mtab: Permission denied
can't rename /etc/mtab.tmp to /etc/mtab: Permission denied


Er...what? Permission denied for root to rename?

It's probably SELinux. It's always SELinux. Sure enough:

# ls -laZ /etc/mtab
-rw-r--r--. root root system_u:object_r:system_conf_t:s0 /etc/mtab
# restorecon /etc/mtab
# ls -laZ /etc/mtab
-rw-r--r--. root root system_u:object_r:etc_runtime_t:s0 /etc/mtab


Now it works fine:

# tuned-adm profile virtual-host
Reverting to saved sysctl settings: [ OK ]
Calling '/etc/ktune.d/tunedadm.sh stop': [ OK ]
Stopping tuned: [ OK ]
Switching to profile 'virtual-host'
Applying ktune sysctl settings:
/etc/ktune.d/tunedadm.conf: [ OK ]
Calling '/etc/ktune.d/tunedadm.sh start': [ OK ]
Applying sysctl settings from /etc/sysctl.conf
Starting tuned: [ OK ]

An observation: each time you apply a tuned profile (for example, going back to the default and then to a non-default again), tuned-adm may append options to /etc/mtab. For example, we start with the following line in /etc/mtab:

/dev/mapper/[UUID] /rhev/data-center/mnt/blockSD/[UUID] ext3 rw,barrier 0 0


After doing

# tuned-adm profile virtual-host
# tuned-adm profile default
# tuned-adm profile virtual-host

the line in /etc/mtab looks like this:

/dev/mapper/[UUID] /rhev/data-center/mnt/blockSD/[UUID] ext3 rw,barrier,nobarrier,barrier,nobarrier 0 0


This was a bit confusing, but since mount and umount maintain /etc/mtab I assume they know what they're doing. Interestingly, after a reboot, /proc/mounts says:

/dev/mapper/[UUID] /rhev/data-center/mnt/blockSD/[UUID] ext3 rw,seclabel,relatime,errors=continue,barrier=1,data=ordered 0 0


That makes me sleep a little better, given the dire warnings about running ext3 without barrier=1.