I don't fully understand it yet, but I was forced to learn a little bit of SELinux recently. I have known that Fedora Cores 1, 2 and 3 came with SELinux (Security Enhanced Linux developed by the NSA) for some time, but it did not affect the operation of my system until recently when PosrgreSQL failed to start after a reboot.

There were messages in the system log like this:

Dec 25 17:50:47 gao-2004 kernel: audit(1104018647.963:0): avc:  denied  { read }
 for  pid=10109 exe=/usr/bin/postgres name=PG_VERSION dev=hda3 ino=950339 sconte
xt=root:system_r:postgresql_t tcontext=root:object_r:var_lib_t tclass=file

At first glance I thought this must be a permissions problem. But the permission on the PG_VERSION file looked OK:

-rw-------  1 postgres postgres 4 Nov 13 22:31 PG_VERSION

A few minutes of Googling lead me to the many postings on the Fedora Core mailing list, and ultimately to the Fedora Core 3 SELinux FAQ. I realized that my PostgreSQL RPMs had been automatically updated by yum the day before, and the server is locked down by SELinux now.

I'll spare you the theory behind SELinux, because it's all in the FAQ, and only mention a few interesting bits.

A -Z switch has been added to the ls, id and ps commands to display the security context:

[weiqi@gao] $ pgrep postmaster | xargs ps -Zw
LABEL                             PID TTY      STAT   TIME COMMAND
user_u:system_r:postgresql_t     2603 ?        S      0:00 /usr/bin/postmaster -
p 5432 -D /var/lib/pgsql/data
user_u:system_r:postgresql_t     2605 ?        S      0:00 postgres: stats buffe
r process
user_u:system_r:postgresql_t     2606 ?        S      0:00 postgres: stats colle
ctor process

[root@gao] # ls -Z /var/lib/pgsql/data/PG_VERSION
-rw-------  postgres postgres system_u:object_r:postgresql_db_t /var/lib/pgsql/d
ata/PG_VERSION

In order for a process to be able to read a file, the security context of the process and of the file must be related in such a way in the SELinux pilicy file that allows the reading.

The problem I had was that my PG_VERSION file's security context was out of whack. Fortunately, the SELinux policy file also defines what the security context of every file in the system should be. The restorecon command can be used to correct the error. So I ran

[root@gao] $ restorecon -R /var/lib/pgsql

to get the security context right. And that fixed my problem.

Yesterday, MySQL, after being updated overnight, wouldn't start on reboot. And this time I know what to try. Sure enough, restorecon did the trick.

Responses[3]

Posted by Weiqi Gao on January 9, 2005 7:45:33 AM CST #