Hi,
I have installed a second harddisk that was mounted as /home1. To free up my / filesystem a bit, I moved /var/lib/pgsql to /home1/pgsql with mv it retained the original contexts and then created a symlink at the original place.
Now, postgresql doesn't start unless I exclude it from SELinux. Furthermore, "fixfiles relabel /home1" destroyed the file contexts under /home1/pgsql.
I tried to RTFM on SELinux contexts and permissions, discovering that I need to install selinux-policy.noarch so I can finetune the policy. But no files under /usr/share/selinux/devel/include/ contain references to /var/lib/pgsql, not even /usr/share/selinux/devel/include/services/postgresql.if.
So, how can I fix the current situation and include /home1/pgsql in the postgresql context/domain? I would like to relabel it to recover the context...
BTW the same principle would apply if one would like to create another tablespace for postgresql under another mount point...
Best regards, Zoltán Böszörményi
Hi,
answering to myself. :-)
Zoltan Boszormenyi írta:
So, how can I fix the current situation and include /home1/pgsql in the postgresql context/domain? I would like to relabel it to recover the context...
BTW the same principle would apply if one would like to create another tablespace for postgresql under another mount point...
After some more RTFM, it would seem simple:
semanage fcontext -a -t postgresql_db_t '/home1/pgsql/data(/.*)?' semanage fcontext -a -t postgresql_log_t '/home1/pgsql/pgstartup.log' fixfiles relabel /home1/pgsql
But it was not enough. Starting it with "service postgresql start" fails. I had to modify the rc script, too. I had to replace /var/lib/pgsql with /home1/pgsql everywhere despite the /var/lib/pgsql -> /home1/pgsql symlink.
But this is enough for adding another tablespace under e.g. /home1/pgsql2:
mkdir -p /home1/pgsql2/data chown -R postgres.postgres /home1/pgsql2 semanage fcontext -a -t postgresql_db_t '/home1/pgsql2/data(/.*)?' fixfiles relabel /home1/pgsql2
Best regards, Zoltán Böszörményi
On Sun, 2006-05-28 at 17:13 +0200, Zoltan Boszormenyi wrote:
Hi,
answering to myself. :-)
Zoltan Boszormenyi írta:
So, how can I fix the current situation and include /home1/pgsql in the postgresql context/domain? I would like to relabel it to recover the context...
BTW the same principle would apply if one would like to create another tablespace for postgresql under another mount point...
After some more RTFM, it would seem simple:
semanage fcontext -a -t postgresql_db_t '/home1/pgsql/data(/.*)?' semanage fcontext -a -t postgresql_log_t '/home1/pgsql/pgstartup.log' fixfiles relabel /home1/pgsql
But it was not enough. Starting it with "service postgresql start" fails. I had to modify the rc script, too. I had to replace /var/lib/pgsql with /home1/pgsql everywhere despite the /var/lib/pgsql -> /home1/pgsql symlink.
This will be failing because SELinux is blocking access to reading the symlink. You should find an avc denial for the lnk_file in your logs.
But this is enough for adding another tablespace under e.g. /home1/pgsql2:
mkdir -p /home1/pgsql2/data chown -R postgres.postgres /home1/pgsql2 semanage fcontext -a -t postgresql_db_t '/home1/pgsql2/data(/.*)?' fixfiles relabel /home1/pgsql2
An easier way is to bind mount /home/pgsql on /var/lib/pgsql etc. and do a restorecon -R on the "new" /var/lib/pgsql. That achieves the same effect without the symlink.
Paul.
Paul Howarth írta:
On Sun, 2006-05-28 at 17:13 +0200, Zoltan Boszormenyi wrote:
Hi,
answering to myself. :-)
Zoltan Boszormenyi írta:
So, how can I fix the current situation and include /home1/pgsql in the postgresql context/domain? I would like to relabel it to recover the context...
BTW the same principle would apply if one would like to create another tablespace for postgresql under another mount point...
After some more RTFM, it would seem simple:
semanage fcontext -a -t postgresql_db_t '/home1/pgsql/data(/.*)?' semanage fcontext -a -t postgresql_log_t '/home1/pgsql/pgstartup.log' fixfiles relabel /home1/pgsql
But it was not enough. Starting it with "service postgresql start" fails. I had to modify the rc script, too. I had to replace /var/lib/pgsql with /home1/pgsql everywhere despite the /var/lib/pgsql -> /home1/pgsql symlink.
This will be failing because SELinux is blocking access to reading the symlink. You should find an avc denial for the lnk_file in your logs.
I haven't found any. :-( Can this difference below cause the problem?
[root@localhost log]# ls -d --scontext /var/lib/pgsql user_u:object_r:var_lib_t /var/lib/pgsql -> /home1/pgsql [root@localhost log]# ls -d --scontext /var/lib/pgsql/ system_u:object_r:default_t /var/lib/pgsql/
Adding /home1/pgsql with var_lib_t context didn't make any difference, though.
But this is enough for adding another tablespace under e.g. /home1/pgsql2:
mkdir -p /home1/pgsql2/data chown -R postgres.postgres /home1/pgsql2 semanage fcontext -a -t postgresql_db_t '/home1/pgsql2/data(/.*)?' fixfiles relabel /home1/pgsql2
An easier way is to bind mount /home/pgsql on /var/lib/pgsql etc. and do a restorecon -R on the "new" /var/lib/pgsql. That achieves the same effect without the symlink.
I know, but the disk I install will be (or already is) used for both my databases and for extending /home. I created only one partition on that disk, so... The system is my home/devel machine and the disk is SATA and fast enough. Although for a high performance production machine, I would always give PostgreSQL it's own disks to separate WAL, table and index spaces.
Best regards, Zoltán Böszörményi
On Sun, 2006-05-28 at 20:33 +0200, Zoltan Boszormenyi wrote:
Paul Howarth írta:
On Sun, 2006-05-28 at 17:13 +0200, Zoltan Boszormenyi wrote:
Hi,
answering to myself. :-)
Zoltan Boszormenyi írta:
So, how can I fix the current situation and include /home1/pgsql in the postgresql context/domain? I would like to relabel it to recover the context...
BTW the same principle would apply if one would like to create another tablespace for postgresql under another mount point...
After some more RTFM, it would seem simple:
semanage fcontext -a -t postgresql_db_t '/home1/pgsql/data(/.*)?' semanage fcontext -a -t postgresql_log_t '/home1/pgsql/pgstartup.log' fixfiles relabel /home1/pgsql
But it was not enough. Starting it with "service postgresql start" fails. I had to modify the rc script, too. I had to replace /var/lib/pgsql with /home1/pgsql everywhere despite the /var/lib/pgsql -> /home1/pgsql symlink.
This will be failing because SELinux is blocking access to reading the symlink. You should find an avc denial for the lnk_file in your logs.
I haven't found any. :-(
Perhaps you won't find any now because it's never trying to access /var/lib/pgsql since you changed the configs to get around the problem? Are there none from first attempt?
Can this difference below cause the problem?
[root@localhost log]# ls -d --scontext /var/lib/pgsql user_u:object_r:var_lib_t /var/lib/pgsql -> /home1/pgsql [root@localhost log]# ls -d --scontext /var/lib/pgsql/ system_u:object_r:default_t /var/lib/pgsql/
Adding /home1/pgsql with var_lib_t context didn't make any difference, though.
The existence of the symlink itself is probably the problem, rather than its context. Applications have to have specific permission to be able to read (and hence follow) symlinks in SELinux.
But this is enough for adding another tablespace under e.g. /home1/pgsql2:
mkdir -p /home1/pgsql2/data chown -R postgres.postgres /home1/pgsql2 semanage fcontext -a -t postgresql_db_t '/home1/pgsql2/data(/.*)?' fixfiles relabel /home1/pgsql2
An easier way is to bind mount /home/pgsql on /var/lib/pgsql etc. and do a restorecon -R on the "new" /var/lib/pgsql. That achieves the same effect without the symlink.
I know, but the disk I install will be (or already is) used for both my databases and for extending /home. I created only one partition on that disk, so... The system is my home/devel machine and the disk is SATA and fast enough. Although for a high performance production machine, I would always give PostgreSQL it's own disks to separate WAL, table and index spaces.
Perhaps you'll use LVM next time :-)
Paul.
Paul Howarth írta:
On Sun, 2006-05-28 at 20:33 +0200, Zoltan Boszormenyi wrote:
Paul Howarth írta:
On Sun, 2006-05-28 at 17:13 +0200, Zoltan Boszormenyi wrote:
Hi,
answering to myself. :-)
Zoltan Boszormenyi írta:
So, how can I fix the current situation and include /home1/pgsql in the postgresql context/domain? I would like to relabel it to recover the context...
BTW the same principle would apply if one would like to create another tablespace for postgresql under another mount point...
After some more RTFM, it would seem simple:
semanage fcontext -a -t postgresql_db_t '/home1/pgsql/data(/.*)?' semanage fcontext -a -t postgresql_log_t '/home1/pgsql/pgstartup.log' fixfiles relabel /home1/pgsql
But it was not enough. Starting it with "service postgresql start" fails. I had to modify the rc script, too. I had to replace /var/lib/pgsql with /home1/pgsql everywhere despite the /var/lib/pgsql -> /home1/pgsql symlink.
This will be failing because SELinux is blocking access to reading the symlink. You should find an avc denial for the lnk_file in your logs.
I haven't found any. :-(
Perhaps you won't find any now because it's never trying to access /var/lib/pgsql since you changed the configs to get around the problem? Are there none from first attempt?
Sorry, I expected the audit messages in /var/log/messages. Yes, I have such messages in audit.log:
type=AVC msg=audit(1148827118.909:2493): avc: denied { read } \ for pid=29719 comm="postmaster" name="pgsql" dev=hdb3 \ ino=1010804 scontext=user_u:system_r:postgresql_t:s0 \ tcontext=user_u:object_r:var_lib_t:s0 tclass=lnk_file type=PATH msg=audit(1148827118.909:2493): item=0 \ name="/var/lib/pgsql/data/postgresql.conf" flags=101
Can this difference below cause the problem?
[root@localhost log]# ls -d --scontext /var/lib/pgsql user_u:object_r:var_lib_t /var/lib/pgsql -> /home1/pgsql [root@localhost log]# ls -d --scontext /var/lib/pgsql/ system_u:object_r:default_t /var/lib/pgsql/
Adding /home1/pgsql with var_lib_t context didn't make any difference, though.
The existence of the symlink itself is probably the problem, rather than its context. Applications have to have specific permission to be able to read (and hence follow) symlinks in SELinux.
So, how can I tweak the policy so postgres can follow just this one symlink?
But this is enough for adding another tablespace under e.g. /home1/pgsql2:
mkdir -p /home1/pgsql2/data chown -R postgres.postgres /home1/pgsql2 semanage fcontext -a -t postgresql_db_t '/home1/pgsql2/data(/.*)?' fixfiles relabel /home1/pgsql2
An easier way is to bind mount /home/pgsql on /var/lib/pgsql etc. and do a restorecon -R on the "new" /var/lib/pgsql. That achieves the same effect without the symlink.
I know, but the disk I install will be (or already is) used for both my databases and for extending /home. I created only one partition on that disk, so... The system is my home/devel machine and the disk is SATA and fast enough. Although for a high performance production machine, I would always give PostgreSQL it's own disks to separate WAL, table and index spaces.
Perhaps you'll use LVM next time :-)
Well, how can you merge two disks with LVM and still be able to record from the BTTV card to only one of them? Having a separate disk dedicates the disk speed to this task while another program can write under /home. Maybe my knowledge is a bit outdated, so enlightenment is welcome. :-)
Best regards, Zoltán Böszörményi
On Sun, 2006-05-28 at 22:14 +0200, Zoltan Boszormenyi wrote:
Paul Howarth írta:
On Sun, 2006-05-28 at 20:33 +0200, Zoltan Boszormenyi wrote:
Paul Howarth írta:
On Sun, 2006-05-28 at 17:13 +0200, Zoltan Boszormenyi wrote:
Hi,
answering to myself. :-)
Zoltan Boszormenyi írta:
So, how can I fix the current situation and include /home1/pgsql in the postgresql context/domain? I would like to relabel it to recover the context...
BTW the same principle would apply if one would like to create another tablespace for postgresql under another mount point...
After some more RTFM, it would seem simple:
semanage fcontext -a -t postgresql_db_t '/home1/pgsql/data(/.*)?' semanage fcontext -a -t postgresql_log_t '/home1/pgsql/pgstartup.log' fixfiles relabel /home1/pgsql
But it was not enough. Starting it with "service postgresql start" fails. I had to modify the rc script, too. I had to replace /var/lib/pgsql with /home1/pgsql everywhere despite the /var/lib/pgsql -> /home1/pgsql symlink.
This will be failing because SELinux is blocking access to reading the symlink. You should find an avc denial for the lnk_file in your logs.
I haven't found any. :-(
Perhaps you won't find any now because it's never trying to access /var/lib/pgsql since you changed the configs to get around the problem? Are there none from first attempt?
Sorry, I expected the audit messages in /var/log/messages. Yes, I have such messages in audit.log:
You must have auditd running (probably a system upgraded from FC4 rather than a clean FC5 install).
type=AVC msg=audit(1148827118.909:2493): avc: denied { read } \ for pid=29719 comm="postmaster" name="pgsql" dev=hdb3 \ ino=1010804 scontext=user_u:system_r:postgresql_t:s0 \ tcontext=user_u:object_r:var_lib_t:s0 tclass=lnk_file type=PATH msg=audit(1148827118.909:2493): item=0 \ name="/var/lib/pgsql/data/postgresql.conf" flags=101
...
The existence of the symlink itself is probably the problem, rather than its context. Applications have to have specific permission to be able to read (and hence follow) symlinks in SELinux.
So, how can I tweak the policy so postgres can follow just this one symlink?
Set yourself up for making local policy modules:
# yum install checkpolicy # cd /root # mkdir selinux.local # cd selinux.local # chcon -R -t usr_t . # ln -s /usr/share/selinux/devel/Makefile .
Make a local policy module for this issue, in this directory: 1. Create a file postgres.te with this content:
module postgres 0.1;
require { class lnk_file read;
type postgresql_t; type var_lib_t; };
# Allow postgres to read /var/lib/pgsql -> /home1/pgsql symlink allow postgresql_t var_lib_t:lnk_file read;
2. Create a file postgres.fc with this content:
/home1/pgsql[^/]*/data(/.*)? gen_context(system_u:object_r:postgresql_db_t,s0)
/home1/pgsql[^/]*/pgstartup.log -- gen_context(system_u:object_r:postgresql_log_t,s0)
(that's two long lines)
3. Create an empty postgres.if file:
# touch postgres.if
4. Build the policy module
# make
Next, remove any file context objects you added for this issue using semanage (contexts will now be managed using your local policy module):
# semanage fcontext -d -t postgresql_db_t '/home1/pgsql/data(/.*)?' # semanage fcontext -d -t postgresql_log_t '/home1/pgsql/pgstartup.log' # semanage fcontext -d -t postgresql_db_t '/home1/pgsql2/data(/.*)?'
Finally, install your new policy module:
# semodule -i postgres.pp
An easier way is to bind mount /home/pgsql on /var/lib/pgsql etc. and do a restorecon -R on the "new" /var/lib/pgsql. That achieves the same effect without the symlink.
I know, but the disk I install will be (or already is) used for both my databases and for extending /home. I created only one partition on that disk, so... The system is my home/devel machine and the disk is SATA and fast enough. Although for a high performance production machine, I would always give PostgreSQL it's own disks to separate WAL, table and index spaces.
Perhaps you'll use LVM next time :-)
Well, how can you merge two disks with LVM and still be able to record from the BTTV card to only one of them? Having a separate disk dedicates the disk speed to this task while another program can write under /home. Maybe my knowledge is a bit outdated, so enlightenment is welcome. :-)
You could create two partitions on the additional disk, one for extending the space on /home and one dedicated to BTTV. Create an LVM physical volume on each partition. Add the first physical volume to the volume group used for /home, then extend the logical volume for /home and resize up the partition. Create a new volume group for BTTV purposes and add the second physical volume to it. Create a new logical volume for BTTV, and create a new filesystem on that logical volume. Since it's in a separate volume group, it will be allocated space only from the fast new drive.
Paul.
Paul Howarth írta:
On Sun, 2006-05-28 at 22:14 +0200, Zoltan Boszormenyi wrote:
Paul Howarth írta:
On Sun, 2006-05-28 at 20:33 +0200, Zoltan Boszormenyi wrote:
Paul Howarth írta:
On Sun, 2006-05-28 at 17:13 +0200, Zoltan Boszormenyi wrote:
Hi,
answering to myself. :-)
Zoltan Boszormenyi írta:
> So, how can I fix the current situation and include /home1/pgsql in > the postgresql context/domain? I would like to relabel it to recover > the context... > > BTW the same principle would apply if one would like to create > another tablespace for postgresql under another mount point... > > > After some more RTFM, it would seem simple:
semanage fcontext -a -t postgresql_db_t '/home1/pgsql/data(/.*)?' semanage fcontext -a -t postgresql_log_t '/home1/pgsql/pgstartup.log' fixfiles relabel /home1/pgsql
But it was not enough. Starting it with "service postgresql start" fails. I had to modify the rc script, too. I had to replace /var/lib/pgsql with /home1/pgsql everywhere despite the /var/lib/pgsql -> /home1/pgsql symlink.
This will be failing because SELinux is blocking access to reading the symlink. You should find an avc denial for the lnk_file in your logs.
I haven't found any. :-(
Perhaps you won't find any now because it's never trying to access /var/lib/pgsql since you changed the configs to get around the problem? Are there none from first attempt?
Sorry, I expected the audit messages in /var/log/messages. Yes, I have such messages in audit.log:
You must have auditd running (probably a system upgraded from FC4 rather than a clean FC5 install).
Actually, no. I was a clean install over my previous FC3. I installed and set auditd to run.
type=AVC msg=audit(1148827118.909:2493): avc: denied { read } \ for pid=29719 comm="postmaster" name="pgsql" dev=hdb3 \ ino=1010804 scontext=user_u:system_r:postgresql_t:s0 \ tcontext=user_u:object_r:var_lib_t:s0 tclass=lnk_file type=PATH msg=audit(1148827118.909:2493): item=0 \ name="/var/lib/pgsql/data/postgresql.conf" flags=101
...
The existence of the symlink itself is probably the problem, rather than its context. Applications have to have specific permission to be able to read (and hence follow) symlinks in SELinux.
So, how can I tweak the policy so postgres can follow just this one symlink?
Set yourself up for making local policy modules:
# yum install checkpolicy # cd /root # mkdir selinux.local # cd selinux.local # chcon -R -t usr_t . # ln -s /usr/share/selinux/devel/Makefile .
Make a local policy module for this issue, in this directory:
- Create a file postgres.te with this content:
module postgres 0.1;
require { class lnk_file read;
type postgresql_t; type var_lib_t;};
# Allow postgres to read /var/lib/pgsql -> /home1/pgsql symlink allow postgresql_t var_lib_t:lnk_file read;
- Create a file postgres.fc with this content:
/home1/pgsql[^/]*/data(/.*)? gen_context(system_u:object_r:postgresql_db_t,s0)
/home1/pgsql[^/]*/pgstartup.log -- gen_context(system_u:object_r:postgresql_log_t,s0)
(that's two long lines)
- Create an empty postgres.if file:
# touch postgres.if
- Build the policy module
# make
Next, remove any file context objects you added for this issue using semanage (contexts will now be managed using your local policy module):
# semanage fcontext -d -t postgresql_db_t '/home1/pgsql/data(/.*)?' # semanage fcontext -d -t postgresql_log_t '/home1/pgsql/pgstartup.log' # semanage fcontext -d -t postgresql_db_t '/home1/pgsql2/data(/.*)?'
Finally, install your new policy module:
# semodule -i postgres.pp
Thanks, it almost worked. After doing these above, I still got avc denied { search } messages like this below:
type=AVC msg=audit(1148979521.381:10): avc: denied { search } for pid=2666 comm="postmaster" name="/" dev=sda1 ino=2 scontext=system_u:system_r:postgresql_t:s0 tcontext=system_u:object_r:default_t:s0 tclass=dir
As it turned out, /home1 was default_t and postgresql is not enabled to search and read files in default_t context. It made it working:
# semanage fcontext -a -t var_lib_t -f -d '/home1' # fixfiles relabel /home1
What puzzled me is starting postgresql failed at boot but not the manual "service postgresql start" after bootup. (Maybe different contexts are applied to the logged-in root and the init program?) The two lines above made it working again.
An easier way is to bind mount /home/pgsql on /var/lib/pgsql etc. and do a restorecon -R on the "new" /var/lib/pgsql. That achieves the same effect without the symlink.
Actually I missed the "bind mount" part. That would have been much easier. But the crash course in SELinux was most fruitful, thank you.
I know, but the disk I install will be (or already is) used for both my databases and for extending /home. I created only one partition on that disk, so... The system is my home/devel machine and the disk is SATA and fast enough. Although for a high performance production machine, I would always give PostgreSQL it's own disks to separate WAL, table and index spaces.
Perhaps you'll use LVM next time :-)
Well, how can you merge two disks with LVM and still be able to record from the BTTV card to only one of them? Having a separate disk dedicates the disk speed to this task while another program can write under /home. Maybe my knowledge is a bit outdated, so enlightenment is welcome. :-)
You could create two partitions on the additional disk, one for extending the space on /home and one dedicated to BTTV. Create an LVM physical volume on each partition. Add the first physical volume to the volume group used for /home, then extend the logical volume for /home and resize up the partition. Create a new volume group for BTTV purposes and add the second physical volume to it. Create a new logical volume for BTTV, and create a new filesystem on that logical volume. Since it's in a separate volume group, it will be allocated space only from the fast new drive.
Thanks for this info. Next time I reinstall my machine (FC6?) I will do a similar scheme.
Sorry for the late answer, yesterday I donated my blood and had to hit the bed earlier that my usual.
Best regards, Zoltán Böszörményi
Zoltan Boszormenyi wrote:
Paul Howarth írta:
You must have auditd running (probably a system upgraded from FC4 rather than a clean FC5 install).
Actually, no. I was a clean install over my previous FC3. I installed and set auditd to run.
OK. I do this myself too, but most people don't...
Set yourself up for making local policy modules:
...
Make a local policy module for this issue, in this directory:
- Create a file postgres.te with this content:
module postgres 0.1;
...
- Create a file postgres.fc with this content:
/home1/pgsql[^/]*/data(/.*)? gen_context(system_u:object_r:postgresql_db_t,s0)
/home1/pgsql[^/]*/pgstartup.log -- gen_context(system_u:object_r:postgresql_log_t,s0)
(that's two long lines)
...
Next, remove any file context objects you added for this issue using semanage (contexts will now be managed using your local policy module):
# semanage fcontext -d -t postgresql_db_t '/home1/pgsql/data(/.*)?' # semanage fcontext -d -t postgresql_log_t '/home1/pgsql/pgstartup.log' # semanage fcontext -d -t postgresql_db_t '/home1/pgsql2/data(/.*)?'
Finally, install your new policy module:
# semodule -i postgres.pp
Thanks, it almost worked. After doing these above, I still got avc denied { search } messages like this below:
type=AVC msg=audit(1148979521.381:10): avc: denied { search } for pid=2666 comm="postmaster" name="/" dev=sda1 ino=2 scontext=system_u:system_r:postgresql_t:s0 tcontext=system_u:object_r:default_t:s0 tclass=dir
As it turned out, /home1 was default_t and postgresql is not enabled to search and read files in default_t context. It made it working:
# semanage fcontext -a -t var_lib_t -f -d '/home1' # fixfiles relabel /home1
You can incorporate this into your local policy module by adding another line to postgres.fc:
/home1(/pgsql)? -d gen_context(system_u:object_r:var_lib_t,s0)
Bump the version number in postgres.te from 0.1 to 0.2 and re-run make.
You could then remove the extra fcontext object using semanage, and update the policy module: # semodule -i postgres.pp
Having everything in the policy module is better for maintainability I think.
What puzzled me is starting postgresql failed at boot but not the manual "service postgresql start" after bootup. (Maybe different contexts are applied to the logged-in root and the init program?)
Running the initscript should be exactly the same as the boot process. Starting the service manually (without the initscript) would be different though, as no domain transition would happen.
Do the AVCs logged during the boot process show the process running as postgresql_t? If you do a "ps uaxZ", is it running as postgresql_t or unconfined_t?
The two lines above made it working again.
So it's working from bootup now?
An easier way is to bind mount /home/pgsql on /var/lib/pgsql etc. and do a restorecon -R on the "new" /var/lib/pgsql. That achieves the same effect without the symlink.
Actually I missed the "bind mount" part. That would have been much easier. But the crash course in SELinux was most fruitful, thank you.
I've just responded to another poster with almost exactly the same issue. I think this might be worth a wiki page.
Sorry for the late answer, yesterday I donated my blood and had to hit the bed earlier that my usual.
No problem, we all have to sleep!
Cheers, Paul.
Paul Howarth írta:
Zoltan Boszormenyi wrote:
Paul Howarth írta:
Set yourself up for making local policy modules:
...
Make a local policy module for this issue, in this directory:
- Create a file postgres.te with this content:
module postgres 0.1;
...
- Create a file postgres.fc with this content:
/home1/pgsql[^/]*/data(/.*)? gen_context(system_u:object_r:postgresql_db_t,s0)
/home1/pgsql[^/]*/pgstartup.log -- gen_context(system_u:object_r:postgresql_log_t,s0)
(that's two long lines)
...
Next, remove any file context objects you added for this issue using semanage (contexts will now be managed using your local policy module):
# semanage fcontext -d -t postgresql_db_t '/home1/pgsql/data(/.*)?' # semanage fcontext -d -t postgresql_log_t '/home1/pgsql/pgstartup.log' # semanage fcontext -d -t postgresql_db_t '/home1/pgsql2/data(/.*)?'
Finally, install your new policy module:
# semodule -i postgres.pp
Thanks, it almost worked. After doing these above, I still got avc denied { search } messages like this below:
type=AVC msg=audit(1148979521.381:10): avc: denied { search } for pid=2666 comm="postmaster" name="/" dev=sda1 ino=2 scontext=system_u:system_r:postgresql_t:s0 tcontext=system_u:object_r:default_t:s0 tclass=dir
As it turned out, /home1 was default_t and postgresql is not enabled to search and read files in default_t context. It made it working:
# semanage fcontext -a -t var_lib_t -f -d '/home1' # fixfiles relabel /home1
You can incorporate this into your local policy module by adding another line to postgres.fc:
/home1(/pgsql)? -d gen_context(system_u:object_r:var_lib_t,s0)
Bump the version number in postgres.te from 0.1 to 0.2 and re-run make.
You could then remove the extra fcontext object using semanage, and update the policy module: # semodule -i postgres.pp
Having everything in the policy module is better for maintainability I think.
You are right. Thanks.
What puzzled me is starting postgresql failed at boot but not the manual "service postgresql start" after bootup. (Maybe different contexts are applied to the logged-in root and the init program?)
Running the initscript should be exactly the same as the boot process. Starting the service manually (without the initscript) would be different though, as no domain transition would happen.
Both
service postgresql start
and
su - postgres PGDATA=/home1/pgsql pg_ctl start
started successfully if I logged in as root or under "su -" from my mortal uid. (The postgresql initscript uses "runuser" instead of "su" IIRC.)
Do the AVCs logged during the boot process show the process running as postgresql_t? If you do a "ps uaxZ", is it running as postgresql_t or unconfined_t?
It's running under postgresql_t.
The two lines above made it working again.
So it's working from bootup now?
Yes.
> An easier way is to bind mount /home/pgsql on /var/lib/pgsql > etc. and do > a restorecon -R on the "new" /var/lib/pgsql. That achieves the same > effect without the symlink. >
Actually I missed the "bind mount" part. That would have been much easier. But the crash course in SELinux was most fruitful, thank you.
I've just responded to another poster with almost exactly the same issue. I think this might be worth a wiki page.
It would be a good idea.
Sorry for the late answer, yesterday I donated my blood and had to hit the bed earlier that my usual.
No problem, we all have to sleep!
Of course :-)
Best regards, Zoltán Böszörményi
Zoltan Boszormenyi wrote:
Paul Howarth írta:
Zoltan Boszormenyi wrote:
What puzzled me is starting postgresql failed at boot but not the manual "service postgresql start" after bootup. (Maybe different contexts are applied to the logged-in root and the init program?)
Running the initscript should be exactly the same as the boot process. Starting the service manually (without the initscript) would be different though, as no domain transition would happen.
Both
service postgresql start
and
su - postgres PGDATA=/home1/pgsql pg_ctl start
started successfully if I logged in as root or under "su -" from my mortal uid. (The postgresql initscript uses "runuser" instead of "su" IIRC.)
Do the AVCs logged during the boot process show the process running as postgresql_t? If you do a "ps uaxZ", is it running as postgresql_t or unconfined_t?
It's running under postgresql_t.
Does it run under postgresql_t if you start it using pg_ctl?
I've just responded to another poster with almost exactly the same issue. I think this might be worth a wiki page.
It would be a good idea.
I'll do that when the other poster's last issue (default file contexts) is resolved.
Paul.
Paul Howarth írta:
Zoltan Boszormenyi wrote:
Paul Howarth írta:
Zoltan Boszormenyi wrote:
What puzzled me is starting postgresql failed at boot but not the manual "service postgresql start" after bootup. (Maybe different contexts are applied to the logged-in root and the init program?)
Running the initscript should be exactly the same as the boot process. Starting the service manually (without the initscript) would be different though, as no domain transition would happen.
Both
service postgresql start
and
su - postgres PGDATA=/home1/pgsql pg_ctl start
started successfully if I logged in as root or under "su -" from my mortal uid. (The postgresql initscript uses "runuser" instead of "su" IIRC.)
Do the AVCs logged during the boot process show the process running as postgresql_t? If you do a "ps uaxZ", is it running as postgresql_t or unconfined_t?
It's running under postgresql_t.
Does it run under postgresql_t if you start it using pg_ctl?
$ su - # service postgresql stop # su - postgres $ PGDATA=/var/lib/pgsql/data pg_ctl start postmaster starting $ ps axuZ | grep post | grep -v bash | grep -v grep | grep -v "su -" | grep -v "ps " user_u:system_r:unconfined_t postgres 5171 0.5 0.3 92280 3808 pts/0 S 18:32 0:00 /usr/bin/postmaster user_u:system_r:unconfined_t postgres 5174 0.0 0.1 81324 1056 pts/0 S 18:32 0:00 postgres: logger process user_u:system_r:unconfined_t postgres 5176 0.0 0.1 92264 1152 pts/0 S 18:32 0:00 postgres: writer process user_u:system_r:unconfined_t postgres 5177 0.0 0.1 82460 992 pts/0 S 18:32 0:00 postgres: stats buffer process user_u:system_r:unconfined_t postgres 5178 0.0 0.1 81456 1196 pts/0 S 18:32 0:00 postgres: stats collector process $ pg_ctl stop $ logout # service postgresql start A(z) postgresql szolgáltatás elindítása: [ OK ] [root@host-81-17-177-202 ~]# ps axuZ | grep post | grep -v bash | grep -v grep | grep -v "su -" | grep -v "ps " user_u:system_r:unconfined_t postgres 5307 9.5 0.3 92284 3808 ? S 18:36 0:00 /usr/bin/postmaster -p 5432 -D /var/lib/pgsql/data user_u:system_r:unconfined_t postgres 5309 0.0 0.1 81328 1056 ? S 18:36 0:00 postgres: logger process user_u:system_r:unconfined_t postgres 5311 0.0 0.1 92268 1112 ? S 18:36 0:00 postgres: writer process user_u:system_r:unconfined_t postgres 5312 0.0 0.0 82464 920 ? S 18:36 0:00 postgres: stats buffer process user_u:system_r:unconfined_t postgres 5313 0.0 0.1 81460 1196 ? S 18:36 0:00 postgres: stats collector process
Both times it's running under unconfined_t, so it doesn't matter whether it's running under "su - postgres" or "runuser - postgres". It seems what matters is that it's started from a logged in user:
# ps auxZ | grep bash user_u:system_r:unconfined_t zozo 4979 0.0 0.1 59836 1708 pts/0 Ss 18:28 0:00 bash user_u:system_r:unconfined_t root 5002 0.0 0.1 59840 1688 pts/0 S 18:28 0:00 -bash
I logged in through GDM if that's interesting, running "su - " in a gnome-terminal.
I've just responded to another poster with almost exactly the same issue. I think this might be worth a wiki page.
It would be a good idea.
I'll do that when the other poster's last issue (default file contexts) is resolved.
Paul.
Best regards, Zoltán Böszörményi
Zoltan Boszormenyi wrote:
Paul Howarth írta:
Zoltan Boszormenyi wrote:
Paul Howarth írta:
Zoltan Boszormenyi wrote:
What puzzled me is starting postgresql failed at boot but not the manual "service postgresql start" after bootup. (Maybe different contexts are applied to the logged-in root and the init program?)
Running the initscript should be exactly the same as the boot process. Starting the service manually (without the initscript) would be different though, as no domain transition would happen.
Both
service postgresql start
and
su - postgres PGDATA=/home1/pgsql pg_ctl start
started successfully if I logged in as root or under "su -" from my mortal uid. (The postgresql initscript uses "runuser" instead of "su" IIRC.)
Do the AVCs logged during the boot process show the process running as postgresql_t? If you do a "ps uaxZ", is it running as postgresql_t or unconfined_t?
It's running under postgresql_t.
Does it run under postgresql_t if you start it using pg_ctl?
$ su - # service postgresql stop # su - postgres $ PGDATA=/var/lib/pgsql/data pg_ctl start postmaster starting $ ps axuZ | grep post | grep -v bash | grep -v grep | grep -v "su -" | grep -v "ps " user_u:system_r:unconfined_t postgres 5171 0.5 0.3 92280 3808 pts/0 S 18:32 0:00 /usr/bin/postmaster user_u:system_r:unconfined_t postgres 5174 0.0 0.1 81324 1056 pts/0 S 18:32 0:00 postgres: logger process user_u:system_r:unconfined_t postgres 5176 0.0 0.1 92264 1152 pts/0 S 18:32 0:00 postgres: writer process user_u:system_r:unconfined_t postgres 5177 0.0 0.1 82460 992 pts/0 S 18:32 0:00 postgres: stats buffer process user_u:system_r:unconfined_t postgres 5178 0.0 0.1 81456 1196 pts/0 S 18:32 0:00 postgres: stats collector process $ pg_ctl stop $ logout
That one's as I expected.
# service postgresql start A(z) postgresql szolgáltatás elindítása: [ OK ] [root@host-81-17-177-202 ~]# ps axuZ | grep post | grep -v bash | grep -v grep | grep -v "su -" | grep -v "ps " user_u:system_r:unconfined_t postgres 5307 9.5 0.3 92284 3808 ? S 18:36 0:00 /usr/bin/postmaster -p 5432 -D /var/lib/pgsql/data user_u:system_r:unconfined_t postgres 5309 0.0 0.1 81328 1056 ? S 18:36 0:00 postgres: logger process user_u:system_r:unconfined_t postgres 5311 0.0 0.1 92268 1112 ? S 18:36 0:00 postgres: writer process user_u:system_r:unconfined_t postgres 5312 0.0 0.0 82464 920 ? S 18:36 0:00 postgres: stats buffer process user_u:system_r:unconfined_t postgres 5313 0.0 0.1 81460 1196 ? S 18:36 0:00 postgres: stats collector process
Both times it's running under unconfined_t, so it doesn't matter whether it's running under "su - postgres" or "runuser - postgres". It seems what matters is that it's started from a logged in user:
I'd have expected this to run as postgresql_t
Is your postgresql initscript correctly labelled as initrc_exec_t?
What's the state of the postgresql_disable_trans boolean? # getsebool postgresql_disable_trans
Paul.
Paul Howarth írta:
Zoltan Boszormenyi wrote:
Paul Howarth írta:
Zoltan Boszormenyi wrote:
Paul Howarth írta:
Zoltan Boszormenyi wrote:
What puzzled me is starting postgresql failed at boot but not the manual "service postgresql start" after bootup. (Maybe different contexts are applied to the logged-in root and the init program?)
Running the initscript should be exactly the same as the boot process. Starting the service manually (without the initscript) would be different though, as no domain transition would happen.
Both
service postgresql start
and
su - postgres PGDATA=/home1/pgsql pg_ctl start
started successfully if I logged in as root or under "su -" from my mortal uid. (The postgresql initscript uses "runuser" instead of "su" IIRC.)
Do the AVCs logged during the boot process show the process running as postgresql_t? If you do a "ps uaxZ", is it running as postgresql_t or unconfined_t?
It's running under postgresql_t.
Does it run under postgresql_t if you start it using pg_ctl?
$ su - # service postgresql stop # su - postgres $ PGDATA=/var/lib/pgsql/data pg_ctl start postmaster starting $ ps axuZ | grep post | grep -v bash | grep -v grep | grep -v "su -" | grep -v "ps " user_u:system_r:unconfined_t postgres 5171 0.5 0.3 92280 3808 pts/0 S 18:32 0:00 /usr/bin/postmaster user_u:system_r:unconfined_t postgres 5174 0.0 0.1 81324 1056 pts/0 S 18:32 0:00 postgres: logger process user_u:system_r:unconfined_t postgres 5176 0.0 0.1 92264 1152 pts/0 S 18:32 0:00 postgres: writer process user_u:system_r:unconfined_t postgres 5177 0.0 0.1 82460 992 pts/0 S 18:32 0:00 postgres: stats buffer process user_u:system_r:unconfined_t postgres 5178 0.0 0.1 81456 1196 pts/0 S 18:32 0:00 postgres: stats collector process $ pg_ctl stop $ logout
That one's as I expected.
# service postgresql start A(z) postgresql szolgáltatás elindítása: [ OK ] [root@host-81-17-177-202 ~]# ps axuZ | grep post | grep -v bash | grep -v grep | grep -v "su -" | grep -v "ps " user_u:system_r:unconfined_t postgres 5307 9.5 0.3 92284 3808 ? S 18:36 0:00 /usr/bin/postmaster -p 5432 -D /var/lib/pgsql/data user_u:system_r:unconfined_t postgres 5309 0.0 0.1 81328 1056 ? S 18:36 0:00 postgres: logger process user_u:system_r:unconfined_t postgres 5311 0.0 0.1 92268 1112 ? S 18:36 0:00 postgres: writer process user_u:system_r:unconfined_t postgres 5312 0.0 0.0 82464 920 ? S 18:36 0:00 postgres: stats buffer process user_u:system_r:unconfined_t postgres 5313 0.0 0.1 81460 1196 ? S 18:36 0:00 postgres: stats collector process
Both times it's running under unconfined_t, so it doesn't matter whether it's running under "su - postgres" or "runuser - postgres". It seems what matters is that it's started from a logged in user:
I'd have expected this to run as postgresql_t
Is your postgresql initscript correctly labelled as initrc_exec_t?
Unfortunately not:
# ls --context postgresql -rwxr-xr-x root root user_u:object_r:etc_t postgresql
although other rc scripts are. Relabelled.
# service postgresql restart A(z) postgresql szolgáltatás leállítása: [ OK ] A(z) postgresql szolgáltatás elindítása: [ OK ] # ps axuZ | grep post | grep -v bash | grep -v grep | grep -v "su -" | grep -v "ps " user_u:system_r:postgresql_t postgres 12617 1.2 0.3 92280 3808 ? S 19:22 0:00 /usr/bin/postmaster -p 5432 -D /var/lib/pgsql/data user_u:system_r:postgresql_t postgres 12623 0.0 0.1 81324 1056 ? S 19:22 0:00 postgres: logger process user_u:system_r:postgresql_t postgres 12625 0.0 0.1 92264 1148 ? S 19:22 0:00 postgres: writer process user_u:system_r:postgresql_t postgres 12626 0.0 0.1 82460 992 ? S 19:22 0:00 postgres: stats buffer process user_u:system_r:postgresql_t postgres 12627 0.0 0.1 81456 1196 ? S 19:22 0:00 postgres: stats collector process
Now it is postgresql_t. It must have been "joe", the editor I used for modifying the rc script. It renamed the original to postgresql~ and created a new file with the modified content. The new file got some default policy from the directory it resides in. Should I always use "vi" to edit such config files? It saves the file in place. Or joe needs some fixup.
What's the state of the postgresql_disable_trans boolean? # getsebool postgresql_disable_trans
# getsebool postgresql_disable_trans postgresql_disable_trans --> off
Best regards, Zoltán Böszörményi
On Wed, 2006-05-31 at 19:40 +0200, Zoltan Boszormenyi wrote:
Paul Howarth írta:
Zoltan Boszormenyi wrote:
Paul Howarth írta:
Zoltan Boszormenyi wrote:
Paul Howarth írta:
Zoltan Boszormenyi wrote: > What puzzled me is starting postgresql failed at boot > but not the manual "service postgresql start" after bootup. > (Maybe different contexts are applied to the logged-in root > and the init program?)
Running the initscript should be exactly the same as the boot process. Starting the service manually (without the initscript) would be different though, as no domain transition would happen.
Both
service postgresql start
and
su - postgres PGDATA=/home1/pgsql pg_ctl start
started successfully if I logged in as root or under "su -" from my mortal uid. (The postgresql initscript uses "runuser" instead of "su" IIRC.)
Do the AVCs logged during the boot process show the process running as postgresql_t? If you do a "ps uaxZ", is it running as postgresql_t or unconfined_t?
It's running under postgresql_t.
Does it run under postgresql_t if you start it using pg_ctl?
$ su - # service postgresql stop # su - postgres $ PGDATA=/var/lib/pgsql/data pg_ctl start postmaster starting $ ps axuZ | grep post | grep -v bash | grep -v grep | grep -v "su -" | grep -v "ps " user_u:system_r:unconfined_t postgres 5171 0.5 0.3 92280 3808 pts/0 S 18:32 0:00 /usr/bin/postmaster user_u:system_r:unconfined_t postgres 5174 0.0 0.1 81324 1056 pts/0 S 18:32 0:00 postgres: logger process user_u:system_r:unconfined_t postgres 5176 0.0 0.1 92264 1152 pts/0 S 18:32 0:00 postgres: writer process user_u:system_r:unconfined_t postgres 5177 0.0 0.1 82460 992 pts/0 S 18:32 0:00 postgres: stats buffer process user_u:system_r:unconfined_t postgres 5178 0.0 0.1 81456 1196 pts/0 S 18:32 0:00 postgres: stats collector process $ pg_ctl stop $ logout
That one's as I expected.
# service postgresql start A(z) postgresql szolgáltatás elindítása: [ OK ] [root@host-81-17-177-202 ~]# ps axuZ | grep post | grep -v bash | grep -v grep | grep -v "su -" | grep -v "ps " user_u:system_r:unconfined_t postgres 5307 9.5 0.3 92284 3808 ? S 18:36 0:00 /usr/bin/postmaster -p 5432 -D /var/lib/pgsql/data user_u:system_r:unconfined_t postgres 5309 0.0 0.1 81328 1056 ? S 18:36 0:00 postgres: logger process user_u:system_r:unconfined_t postgres 5311 0.0 0.1 92268 1112 ? S 18:36 0:00 postgres: writer process user_u:system_r:unconfined_t postgres 5312 0.0 0.0 82464 920 ? S 18:36 0:00 postgres: stats buffer process user_u:system_r:unconfined_t postgres 5313 0.0 0.1 81460 1196 ? S 18:36 0:00 postgres: stats collector process
Both times it's running under unconfined_t, so it doesn't matter whether it's running under "su - postgres" or "runuser - postgres". It seems what matters is that it's started from a logged in user:
I'd have expected this to run as postgresql_t
Is your postgresql initscript correctly labelled as initrc_exec_t?
Unfortunately not:
# ls --context postgresql -rwxr-xr-x root root user_u:object_r:etc_t postgresql
although other rc scripts are. Relabelled.
That explains the failure to transition to the postgresql_t domain then.
# service postgresql restart A(z) postgresql szolgáltatás leállítása: [ OK ] A(z) postgresql szolgáltatás elindítása: [ OK ] # ps axuZ | grep post | grep -v bash | grep -v grep | grep -v "su -" | grep -v "ps " user_u:system_r:postgresql_t postgres 12617 1.2 0.3 92280 3808 ? S 19:22 0:00 /usr/bin/postmaster -p 5432 -D /var/lib/pgsql/data user_u:system_r:postgresql_t postgres 12623 0.0 0.1 81324 1056 ? S 19:22 0:00 postgres: logger process user_u:system_r:postgresql_t postgres 12625 0.0 0.1 92264 1148 ? S 19:22 0:00 postgres: writer process user_u:system_r:postgresql_t postgres 12626 0.0 0.1 82460 992 ? S 19:22 0:00 postgres: stats buffer process user_u:system_r:postgresql_t postgres 12627 0.0 0.1 81456 1196 ? S 19:22 0:00 postgres: stats collector process
Now it is postgresql_t.
Good.
It must have been "joe", the editor I used for modifying the rc script. It renamed the original to postgresql~ and created a new file with the modified content. The new file got some default policy from the directory it resides in. Should I always use "vi" to edit such config files? It saves the file in place. Or joe needs some fixup.
Well initscripts aren't really config files and I don't think they should be edited at all. If they need to provide configurability, it should be done by editing something under /etc/sysconfig, e.g. by setting a PGDATA variable in (say) /etc/sysconfig/postgresql (I don't know if the postgresql initscript has such a facility though). The file under /etc/sysconfig can be sourced by the initscript to get the config info.
Having said that, I believe vi will edit the file in place by default. It's what I use for most of my editing tasks anyway.
What's the state of the postgresql_disable_trans boolean? # getsebool postgresql_disable_trans
# getsebool postgresql_disable_trans postgresql_disable_trans --> off
That was the other possible cause of the transition failure.
Paul.
-
Paul Howarth -
Zoltan Boszormenyi