我正在将 CentOS 5.3 系统从 MySQL 迁移到 PostgreSQL。我们的机器设置方式是将最大的磁盘分区挂载到/home
。这不受我控制,由托管提供商管理。无论如何,/home
出于这个原因,我们显然希望数据库文件处于打开状态。
使用 MySQL,我们做了以下工作:
- 编辑
my.cnf
并将设置更改datadir
为/home/mysql
- 添加了新的“文件类型”策略记录(我希望我使用的术语正确),以设置
/home/mysql(/.*)?
为mysqld_db_t
- 开始
restorecon -R /home/mysql
分配标签
一切都很好。
然而,使用 PostgreSQL,我做了以下操作:
- 分别编辑
/etc/init.d/postgresql
并修改了PGDATA
和PGLOG
变量为/home/pgsql/data
和/home/pgsql/pgstartup.log
- 添加了新的策略记录以设置
/home/pgsql/pgstartup.log
为postgresql_log_t
- 添加了新的策略记录以设置
/home/pgsql/data(/.*)?
为postgresql_db_t
- 开始
restorecon -R /home/pgsql
分配标签
此时,我仍然无法启动 PostgreSQL。pgstartup.log 显示:
# cat pgstartup.log
postmaster cannot access the server configuration file "/home/pgsql/data/postgresql.conf": Permission denied
奇怪的是,我没有在/var/log/messages
或中看到任何与此相关的消息/var/log/secure
,但如果我关闭 SElinux,那么一切都正常。
我确保所有权限都是正确的(文件为 600,目录为 700),所有权也是如此(postgres:postgres)。
谁能告诉我我做错了什么?
我使用的 Yum 存储库来自commandprompt.com,版本 8.3.7。
编辑: 我的问题特别提到目录的原因是,如果我对任何其他目录(例如或)/home
执行所有这些步骤,那么它就会按预期工作。/var/lib/pgsql2
/usr/local/pgsql
答案1
答案2
首先检查conf文件上的标签。在Centos5.3系统上查看后,我发现
semanage fcontext -l | grep "postgresql_etc_t"
/etc/postgresql(/.*)? all files system_u:object_r:postgresql_etc_t:s0
政策规定
sesearch -A -s postgresql_t -t postgresql_etc_t
Found 3 av rules:
allow postgresql_t postgresql_etc_t : file { ioctl read getattr lock };
allow postgresql_t postgresql_etc_t : dir { ioctl read getattr lock search };
allow postgresql_t postgresql_etc_t : lnk_file { read getattr };
尝试做一个
ls -Z /home/pgsql/data/postgresql.conf
如果标签不正确,有多种方法可以更改它。谷歌搜索后,我找到了http://docs.fedoraproject.org/selinux-user-guide/f10/en-US/sect-Security-Enhanced_Linux-SELinux_Contexts_Labeling_Files-Persistent_Changes_semanage_fcontext.html
semanage 是一种方法。如果你想尝试快速测试一下,可以尝试
chcon -t postgresql_etc_t /home/pgsql/data/postgresql.conf
还要确保 postgresql 守护进程在正确的域(即 SELinux 上下文)中运行。通过跟踪日志,您可能很快会发现它不在正确的域中,请参见下文。有关启动 init 脚本的详细信息,请参阅 run_init,以便它位于正确的域中。posgresql 可能以 unconfined_t 的身份运行(在这种情况下应该没有问题,unconfined 可以做很多事情)。
SELinux 可能还存在其他问题,如需进一步分析,请尝试跟踪审计日志。(请注意,审计日志直到 auditd 启动后才会写入,我之前就遇到过这种情况。在这种情况下,请检查 /var/log/messages 中是否存在 auditd 之前的日志消息)
尝试看看 SELinux 可能会抱怨什么
tail -f /var/log/audit/audit.log
或者只寻找否认
tail -f /var/log/audit/audit.log | grep denied
然后尝试相同的访问,即启动守护进程。
答案3
你看过你的#SESTATUS 了吗
[root@yeswedeal ~]# sestatus SELinux 状态:已禁用
答案4
即使您正确标记了目录,selinux 策略也很可能禁止 postgresql 访问/home
自身(事实上,@Milen 的回答中提到的链接似乎暗示了这一点)。