the

Little Projects

of Shawn M. Jones

I’m renting a new server from my dedicated server company, and got a really good deal.

I’ve wanted SELinux with my Red Hat/CentOS/Scientific Linux/Fedora servers since Red Hat ironed out the details around Fedora 6. The benefits are that someone breaking into one of the services is “sandboxed” and it limits the damage they can do to the system.

The drawbacks are that often items don’t function as one would expect because you have not found the correct set of draconian rules to enable the functionality you are looking for, but Red Hat has worked to iron out a lot of that to great success in the last few years.

I changed my SELinux setting in /etc/selinux/config from “disabled” to “permissive” so I can start up services and monitor /var/log/audit/audit.log to determine which SELinux rules should be altered.

After rebooting my server and analyzing the logs, I used the fixfiles command to change the SELinux contexts to get rid of some errors and saw the following message on several files:


failed to change context of `/etc/resolv.conf' to `system_u:object_r:net_conf_t:s0': Operation not permitted


I assumed (wrongly) that this must be some issue with SELinux. I tried the chcon command and got the same message. I could run chcon fine on other files, so what was the problem?

I decided maybe something was up with the file inode, so I tried moving the file aside with the intent of filling it in with the proper data/permissions/etc. after. The cp and mv commands also returned with Operation not permitted.

The permissions on the file showed that the files were owned by root and root had write permission to the file:

-rw-r--r--. 1 root root 97 May 31 17:39 resolv.conf

Now this was less an SELinux problem and more an issue specific to these files. Some more goggling led me to the obscure lsattr command, which showed:

----i---------- /etc/resolv.conf

The i is the “immutable bit”. It is the Linux equivalent to Microsoft Windows’s “Read Only” checkbox. I had known about it, but could not remember the command to check for it.

Removing the immutable bit was easy using chattr:

chattr -i /etc/resolv.conf

And then I was able to run fixfiles, chcon, mv, cp, and whatever else I wanted on the given files.

I’m guessing the admins at the server hosting company had set the bit inadvertently during installation of the system.