bob

Soon after I installed Fedora Core 5 (FC5) on my server, I found that after a reboot httpd would not be running even though my SYSV startup system should have been starting it. I subsequently found if I ran ‘# httpd’ from the command line as root it would start, but if I tried to use the SYSV startup script (’# service httpd start’) it would silently fail to start.

It turned out to be a selinux problem. Recall that FC5’s “targeted policy” for selinux is to restrict only the most dangerous processes, i.e. internet services. I guess that when you run httpd from the command line it has no special role, but when you run it from the SYSV system it has a restricted role (httpd_t). In my case I was doing something the typical setup wouldn’t do (reading in a HTTPS SSL password from a file) which selinux was crushing. The evidence for this was in the /var/log/messages file.

I went through a process of modifying the selinux policy until things worked. Sometimes giving permission for one operation would just cause it to try a new operation that was forbidden, so it took several iterations of trying it, checking /var/log/messages for audit messages, changing the policy, and trying again. Eventually I would up with the following list of audit messages that needed to be corrected:

Jul 30 11:31:33 cecosstream kernel: audit(1154284293.730:20592): avc: denied { execute } for pid=9248 comm=”httpd” name=”ssl.key.dialog” dev=hda2 ino=164115 scontext=user_u:system_r:httpd_t:s0 tcontext=user_u:object_r:httpd_config_t:s0 tclass=file
Jul 31 21:32:25 cecosstream kernel: audit(1154406745.527:20607): avc: denied { execute_no_trans } for pid=21243 comm=”httpd” name=”ssl.key.dialog” dev=hda2 ino=164115 scontext=user_u:system_r:httpd_t:s0 tcontext=user_u:object_r:httpd_config_t:s0 tclass=file
Jul 31 21:35:55 cecosstream kernel: audit(1154406955.512:20609): avc: denied { getattr } for pid=21280 comm=”ssl.key.dialog” name=”utmp” dev=hda2 ino=1111943 scontext=user_u:system_r:httpd_t:s0 tcontext=system_u:object_r:initrc_var_run_t:s0 tclass=file
Jul 31 21:37:46 cecosstream kernel: audit(1154407066.335:20613): avc: denied { read write } for pid=21324 comm=”ssl.key.dialog” name=”utmp” dev=hda2 ino=1111943 scontext=user_u:system_r:httpd_t:s0 tcontext=system_u:object_r:initrc_var_run_t:s0 tclass=file
Jul 31 21:40:17 cecosstream kernel: audit(1154407217.324:20623): avc: denied { lock } for pid=21370 comm=”ssl.key.dialog” name=”utmp” dev=hda2 ino=1111943 scontext=user_u:system_r:httpd_t:s0 tcontext=system_u:object_r:initrc_var_run_t:s0 tclass=file

Here’s the process to turn some audit messages into policy that will allow the transactions to take place:

# audit2allow -m local_20060731 -l < audit_20060731.txt > local_20060731.te
# checkmodule -M -m -o local_20060731.mod ./local_20060731.te
checkmodule: loading policy configuration from ./local_20060731.te
checkmodule: policy configuration loaded
checkmodule: writing binary representation (version 5) to local_20060731.mod
# semodule_package -o local_20060731.pp -m local_20060731.mod
# semodule -i ./local_20060731.pp

where audit_*.txt contains a list of all the avc denied messages from /var/log/messages.

OK, I’m not writing these posts with the expectation that any of my friends will want to read them, but in the hopes that they get into google and help some stranger somewhere solve a problem.

I installed lyceum blogging software (it’s a multi-user variant of wordpress) on my web server several weeks ago. It uses a mysql database as the backend. It worked fine for several weeks, until my server rebooted for the first time. After that, all my lyceum web pages were broken or had no content, and the lyceum error log had tons of entries more or less like this:

=====database error=====
Error#: 1033
Error: Incorrect information in file: ‘./uv_lyceum/options.frm’
Query: SELECT option_value FROM options WHERE option_domain = ’system’ AND option_name = ‘template’ LIMIT 1
========================

It turns out what happened is this: when I installed lyceum, it created its DBs using a mysql backend called innodb. A few weeks later I installed some other package (drupal I think) that suggested putting “skip innodb” in my /etc/my.cnf file. I did so, but it didn’t take effect because I didn’t restart mysqld. When my machine rebooted, mysql started in a state unable to deal with innodb files. That’s what caused the above, relatively uninformative, error message. All I had to do to fix it was comment out the skip innodb line in my.cnf, and restart mysqld.