1:42 p.m.
Hello!
On my FC5 server, I wanted to configure postgresql to use
/home/pgsql/data instead of /var/lib/pgsql/data. (/home partition is
huge and doesn't get formatted when system is upgraded or new system
installed.) I created the directory, ran initdb; everything seemed ok.
Research seemed to tell me that I should perform the reconfiguration in
/etc/sysconfig/pgsql. However, I could not start the service when the
new directory was specified there. Much experimentation led me to this:
[root@citadel ~]# rm -f /home/pgsql/pgstartup.log
[root@citadel ~]# cp /etc/rc.d/init.d/postgresql
/etc/rc.d/init.d/postgresql2
cp: overwrite `/etc/rc.d/init.d/postgresql2'? y
[root@citadel ~]# cp /etc/sysconfig/pgsql/postgresql
/etc/sysconfig/pgsql/postgresql2
cp: overwrite `/etc/sysconfig/pgsql/postgresql2'? y
[root@citadel ~]# cat /etc/sysconfig/pgsql/postgresql
PGDATA=/home/pgsql/data
PGLOG=/home/pgsql/pgstartup.log
[root@citadel ~]# service postgresql start
Starting postgresql service: [FAILED]
[root@citadel ~]# service postgresql2 start
Starting postgresql2 service: [ OK ]
[root@citadel ~]# service postgresql2 stop
Stopping postgresql2 service: [ OK ]
[root@citadel ~]# cat /home/pgsql/pgstartup.log
postmaster cannot access the server configuration file
"/home/pgsql/data/postgresql.conf": Permission denied
LOG: logger shutting down
[root@citadel ~]#
To sum up: I made an exact copy of the server startup script and an
exact copy of my configuration script. The copy starts, but the original
fails.
Obviously, I'm missing something fundamental here. Any help is
appreciated as I am at the end of ideas.
2:05 p.m.
Hi,
i had the same problem on my FC4 system. The problem is caused by SELinux. You
can just disable SELinux on the whole system or disable SELinux for
postgresql.
The proper way would be to set the correct security contexts to
the /home/pgsql directory (using ls -Z and chcon). I haven't tried this, but
AFAIK it should work.
Regards,
Andreas
On Tuesday 23 May 2006 20:42, Alan M. Evans wrote:
Hello!
On my FC5 server, I wanted to configure postgresql to use
/home/pgsql/data instead of /var/lib/pgsql/data. (/home partition is
huge and doesn't get formatted when system is upgraded or new system
installed.) I created the directory, ran initdb; everything seemed ok.
Research seemed to tell me that I should perform the reconfiguration in
/etc/sysconfig/pgsql. However, I could not start the service when the
new directory was specified there. Much experimentation led me to this:
[root@citadel ~]# rm -f /home/pgsql/pgstartup.log
[root@citadel ~]# cp /etc/rc.d/init.d/postgresql
/etc/rc.d/init.d/postgresql2
cp: overwrite `/etc/rc.d/init.d/postgresql2'? y
[root@citadel ~]# cp /etc/sysconfig/pgsql/postgresql
/etc/sysconfig/pgsql/postgresql2
cp: overwrite `/etc/sysconfig/pgsql/postgresql2'? y
[root@citadel ~]# cat /etc/sysconfig/pgsql/postgresql
PGDATA=/home/pgsql/data
PGLOG=/home/pgsql/pgstartup.log
[root@citadel ~]# service postgresql start
Starting postgresql service: [FAILED]
[root@citadel ~]# service postgresql2 start
Starting postgresql2 service: [ OK ]
[root@citadel ~]# service postgresql2 stop
Stopping postgresql2 service: [ OK ]
[root@citadel ~]# cat /home/pgsql/pgstartup.log
postmaster cannot access the server configuration file
"/home/pgsql/data/postgresql.conf": Permission denied
LOG: logger shutting down
[root@citadel ~]#
To sum up: I made an exact copy of the server startup script and an
exact copy of my configuration script. The copy starts, but the original
fails.
Obviously, I'm missing something fundamental here. Any help is
appreciated as I am at the end of ideas.
3:49 p.m.
On Tue, 2006-05-23 at 12:05, Andreas Roth wrote:
i had the same problem on my FC4 system. The problem is caused by
SELinux. You
can just disable SELinux on the whole system or disable SELinux for
postgresql.
The proper way would be to set the correct security contexts to
the /home/pgsql directory (using ls -Z and chcon). I haven't tried this, but
AFAIK it should work.
Thanks. Disabling SELinux for postgresql allowed service startup.
Although I feel a bit creepy about disabling security in order to get
something working. Kind of like leaving one particular door unlocked so
the janitor can get in...
I jacked around with the file security contexts with no luck. I hold
onto the hope that this can be made to work: SELinux and postgresql
living in harmony. Does anyone have a pointer to a crash course in
configuring SELinux security contexts?
4:31 a.m.
Alan M. Evans wrote:
On Tue, 2006-05-23 at 12:05, Andreas Roth wrote:
> i had the same problem on my FC4 system. The problem is caused by SELinux. You
> can just disable SELinux on the whole system or disable SELinux for
> postgresql.
> The proper way would be to set the correct security contexts to
> the /home/pgsql directory (using ls -Z and chcon). I haven't tried this, but
> AFAIK it should work.
Thanks. Disabling SELinux for postgresql allowed service startup.
I hope you used permissive mode rather than fully disabling SELinux.
Otherwise, you'll be in for a long wait whilst your whole system is
relabelled if you re-enabled SELinux.
Although I feel a bit creepy about disabling security in order to
get
something working. Kind of like leaving one particular door unlocked so
the janitor can get in...
Yes, I agree.
I jacked around with the file security contexts with no luck. I hold
onto the hope that this can be made to work: SELinux and postgresql
living in harmony. Does anyone have a pointer to a crash course in
configuring SELinux security contexts?
Compare the file contexts of the default location for the files with the
file contexts you have in your new location.
$ ls -lZa /home/pgsql
Repeat for the default locations of everything you moved. Post the
output you get.
An alternative approach that often works is to bind mount the directory
you want to use for your database/webserver/whatever to the default
location and then use restorecon to fix the contexts.
Paul.
1:54 p.m.
On Wed, 2006-05-24 at 02:31, Paul Howarth wrote:
Alan M. Evans wrote:
> On Tue, 2006-05-23 at 12:05, Andreas Roth wrote:
>> i had the same problem on my FC4 system. The problem is caused by SELinux. You
>> can just disable SELinux on the whole system or disable SELinux for
>> postgresql.
>> The proper way would be to set the correct security contexts to
>> the /home/pgsql directory (using ls -Z and chcon). I haven't tried this, but
>> AFAIK it should work.
>
> Thanks. Disabling SELinux for postgresql allowed service startup.
I hope you used permissive mode rather than fully disabling SELinux.
Otherwise, you'll be in for a long wait whilst your whole system is
relabelled if you re-enabled SELinux.
Well, disabled only for postgresql, as per the checkbox in
system-config-securitylevel. I don't think this will be a problem at
present -- there's nothing on the system worth compromising. And the
firewall should prevent the outside world accessing the database
directly. Nothing on the webserver exposes the database yet.
This thread is about me trying to understand and setup the security
properly so that the server can one day safely face the world.
> Although I feel a bit creepy about disabling security in order
to get
> something working. Kind of like leaving one particular door unlocked so
> the janitor can get in...
Yes, I agree.
> I jacked around with the file security contexts with no luck. I hold
> onto the hope that this can be made to work: SELinux and postgresql
> living in harmony. Does anyone have a pointer to a crash course in
> configuring SELinux security contexts?
Compare the file contexts of the default location for the files with the
file contexts you have in your new location.
$ ls -lZa /home/pgsql
Repeat for the default locations of everything you moved. Post the
output you get.
[root@citadel ~]# ls -lZa /home/pgsql
drwx--x--x postgres postgres system_u:object_r:user_home_dir_t .
drwxr-xr-x root root system_u:object_r:home_root_t ..
drwx------ postgres postgres system_u:object_r:postgresql_db_t data
-rw------- postgres postgres system_u:object_r:postgresql_log_t
pgstartup.log
[root@citadel ~]# ls -lZa /var/lib/pgsql
drwx------ postgres postgres system_u:object_r:var_lib_t .
drwxr-xr-x root root system_u:object_r:var_lib_t ..
drwx------ postgres postgres system_u:object_r:var_lib_t backups
drwx------ postgres postgres system_u:object_r:postgresql_db_t data
-rw------- postgres postgres system_u:object_r:postgresql_log_t
pgstartup.log
[root@citadel ~]#
The security contexts and file permissions/ownerships are identical for
everything in the data directory. I even tried moving the /var/lib/pgsql
directory into home to be supremely certain that the contexts were the
same. No joy.
At one time or another, I set /home/pgsql to the var_lib_t context (and
I think /home as well) in a desperate act of, "Can I get it to work at
all?" Still didn't work, although I don't feel like it was the correct
solution anyway.
An alternative approach that often works is to bind mount the
directory
you want to use for your database/webserver/whatever to the default
location and then use restorecon to fix the contexts.
I don't exactly understand how this would differ substantially from
moving the original directory to the new parent, as I did.
But that's not surprising. I clearly don't understand a lot. I'm trying,
and I really want to do (and understand) the correct and proper method.
One would have thought that simply moving the DB data directory would be
a pretty common scenario, but it seems that SELinux makes this a
complicated task.
8:45 p.m.
On Thu, 2006-05-25 at 11:54 -0700, Alan M. Evans wrote:
...[snip]... there's nothing on the system worth compromising.
And the
firewall should prevent the outside world accessing the database
directly. Nothing on the webserver exposes the database yet.
This thread is about me trying to understand and setup the security
properly so that the server can one day safely face the world.
Seeing as you mentioned the important bit in the last sentence, I'll say
the mantra: Just because you don't think there's anything worth losing
on your box, doesn't mean that someone else doesn't think your box is
worth taking over so that they can do what they want (which could be
anything).
--
(Currently running FC4, in case that's important to the thread)
Don't send private replies to my address, the mailbox is ignored.
I read messages from the public lists.
4:28 a.m.
Alan M. Evans wrote:
On Wed, 2006-05-24 at 02:31, Paul Howarth wrote:
> Alan M. Evans wrote:
>> On Tue, 2006-05-23 at 12:05, Andreas Roth wrote:
>>> i had the same problem on my FC4 system. The problem is caused by SELinux.
You
>>> can just disable SELinux on the whole system or disable SELinux for
>>> postgresql.
>>> The proper way would be to set the correct security contexts to
>>> the /home/pgsql directory (using ls -Z and chcon). I haven't tried this,
but
>>> AFAIK it should work.
>> Thanks. Disabling SELinux for postgresql allowed service startup.
> I hope you used permissive mode rather than fully disabling SELinux.
> Otherwise, you'll be in for a long wait whilst your whole system is
> relabelled if you re-enabled SELinux.
Well, disabled only for postgresql, as per the checkbox in
system-config-securitylevel. I don't think this will be a problem at
present -- there's nothing on the system worth compromising. And the
firewall should prevent the outside world accessing the database
directly. Nothing on the webserver exposes the database yet.
This thread is about me trying to understand and setup the security
properly so that the server can one day safely face the world.
>> Although I feel a bit creepy about disabling security in order to get
>> something working. Kind of like leaving one particular door unlocked so
>> the janitor can get in...
> Yes, I agree.
>
>> I jacked around with the file security contexts with no luck. I hold
>> onto the hope that this can be made to work: SELinux and postgresql
>> living in harmony. Does anyone have a pointer to a crash course in
>> configuring SELinux security contexts?
> Compare the file contexts of the default location for the files with the
> file contexts you have in your new location.
>
> $ ls -lZa /home/pgsql
>
> Repeat for the default locations of everything you moved. Post the
> output you get.
[root@citadel ~]# ls -lZa /home/pgsql
drwx--x--x postgres postgres system_u:object_r:user_home_dir_t .
drwxr-xr-x root root system_u:object_r:home_root_t ..
drwx------ postgres postgres system_u:object_r:postgresql_db_t data
-rw------- postgres postgres system_u:object_r:postgresql_log_t
pgstartup.log
[root@citadel ~]# ls -lZa /var/lib/pgsql
drwx------ postgres postgres system_u:object_r:var_lib_t .
drwxr-xr-x root root system_u:object_r:var_lib_t ..
drwx------ postgres postgres system_u:object_r:var_lib_t backups
drwx------ postgres postgres system_u:object_r:postgresql_db_t data
-rw------- postgres postgres system_u:object_r:postgresql_log_t
pgstartup.log
[root@citadel ~]#
The security contexts and file permissions/ownerships are identical for
everything in the data directory. I even tried moving the /var/lib/pgsql
directory into home to be supremely certain that the contexts were the
same. No joy.
At one time or another, I set /home/pgsql to the var_lib_t context (and
I think /home as well) in a desperate act of, "Can I get it to work at
all?" Still didn't work, although I don't feel like it was the correct
solution anyway.
It's a sensible thing to try, but not really the right one as you say.
> An alternative approach that often works is to bind mount the
directory
> you want to use for your database/webserver/whatever to the default
> location and then use restorecon to fix the contexts.
I don't exactly understand how this would differ substantially from
moving the original directory to the new parent, as I did.
But that's not surprising. I clearly don't understand a lot. I'm trying,
and I really want to do (and understand) the correct and proper method.
One would have thought that simply moving the DB data directory would be
a pretty common scenario, but it seems that SELinux makes this a
complicated task.
One of the complications is that an application might try
reading/searching a parent directory of where its files live. If you've
moved its files to live under /home, this is likely to be denied because
most daemons don't need to read/search home directories
(user_home_dir_t) and so don't have the rights under policy to do that.
Clearly this isn't the actual problem you've had because of what you've
described earlier, but it could be similar.
What I suggest you do is:
1. Re-enable SELinux for postgresql.
2. Put SELinux in permissive mode rather than enforcing.
3. Fix all of the file context labels so that they're appropriate (I
think this may already be the case judging from what you show above)
4. Make a note of the time.
5. Start postgresql. It should work because SELinux is in permissive
mode. Do some example work typical of what you'd be using the database
for. Then stop postgresql.
6. There will be a bunch of "avc: denied" messages in /var/log/messages
(or /var/log/audit/audit.log if auditd is running). Post the ones from
after the time you noted in step 4. From that it should be possible to
make a local policy module that will fix the SELinux problems and enable
you to run in enforcing mode again.
Paul.
5:24 p.m.
On Fri, 2006-05-26 at 02:28, Paul Howarth wrote:
Alan M. Evans wrote:
> On Wed, 2006-05-24 at 02:31, Paul Howarth wrote:
>> Alan M. Evans wrote:
>>> On Tue, 2006-05-23 at 12:05, Andreas Roth wrote:
>>>> i had the same problem on my FC4 system. The problem is caused by
SELinux. You
>>>> can just disable SELinux on the whole system or disable SELinux for
>>>> postgresql.
>>>> The proper way would be to set the correct security contexts to
>>>> the /home/pgsql directory (using ls -Z and chcon). I haven't tried
this, but
>>>> AFAIK it should work.
>>> Thanks. Disabling SELinux for postgresql allowed service startup.
>> I hope you used permissive mode rather than fully disabling SELinux.
>> Otherwise, you'll be in for a long wait whilst your whole system is
>> relabelled if you re-enabled SELinux.
>
> Well, disabled only for postgresql, as per the checkbox in
> system-config-securitylevel. I don't think this will be a problem at
> present -- there's nothing on the system worth compromising. And the
> firewall should prevent the outside world accessing the database
> directly. Nothing on the webserver exposes the database yet.
>
> This thread is about me trying to understand and setup the security
> properly so that the server can one day safely face the world.
>
>>> Although I feel a bit creepy about disabling security in order to get
>>> something working. Kind of like leaving one particular door unlocked so
>>> the janitor can get in...
>> Yes, I agree.
>>
>>> I jacked around with the file security contexts with no luck. I hold
>>> onto the hope that this can be made to work: SELinux and postgresql
>>> living in harmony. Does anyone have a pointer to a crash course in
>>> configuring SELinux security contexts?
>> Compare the file contexts of the default location for the files with the
>> file contexts you have in your new location.
>>
>> $ ls -lZa /home/pgsql
>>
>> Repeat for the default locations of everything you moved. Post the
>> output you get.
>
> [root@citadel ~]# ls -lZa /home/pgsql
> drwx--x--x postgres postgres system_u:object_r:user_home_dir_t .
> drwxr-xr-x root root system_u:object_r:home_root_t ..
> drwx------ postgres postgres system_u:object_r:postgresql_db_t data
> -rw------- postgres postgres system_u:object_r:postgresql_log_t
> pgstartup.log
> [root@citadel ~]# ls -lZa /var/lib/pgsql
> drwx------ postgres postgres system_u:object_r:var_lib_t .
> drwxr-xr-x root root system_u:object_r:var_lib_t ..
> drwx------ postgres postgres system_u:object_r:var_lib_t backups
> drwx------ postgres postgres system_u:object_r:postgresql_db_t data
> -rw------- postgres postgres system_u:object_r:postgresql_log_t
> pgstartup.log
> [root@citadel ~]#
>
> The security contexts and file permissions/ownerships are identical for
> everything in the data directory. I even tried moving the /var/lib/pgsql
> directory into home to be supremely certain that the contexts were the
> same. No joy.
>
> At one time or another, I set /home/pgsql to the var_lib_t context (and
> I think /home as well) in a desperate act of, "Can I get it to work at
> all?" Still didn't work, although I don't feel like it was the correct
> solution anyway.
It's a sensible thing to try, but not really the right one as you say.
>> An alternative approach that often works is to bind mount the directory
>> you want to use for your database/webserver/whatever to the default
>> location and then use restorecon to fix the contexts.
>
> I don't exactly understand how this would differ substantially from
> moving the original directory to the new parent, as I did.
>
> But that's not surprising. I clearly don't understand a lot. I'm
trying,
> and I really want to do (and understand) the correct and proper method.
> One would have thought that simply moving the DB data directory would be
> a pretty common scenario, but it seems that SELinux makes this a
> complicated task.
One of the complications is that an application might try
reading/searching a parent directory of where its files live. If you've
moved its files to live under /home, this is likely to be denied because
most daemons don't need to read/search home directories
(user_home_dir_t) and so don't have the rights under policy to do that.
Clearly this isn't the actual problem you've had because of what you've
described earlier, but it could be similar.
What I suggest you do is:
1. Re-enable SELinux for postgresql.
2. Put SELinux in permissive mode rather than enforcing.
3. Fix all of the file context labels so that they're appropriate (I
think this may already be the case judging from what you show above)
4. Make a note of the time.
5. Start postgresql. It should work because SELinux is in permissive
mode. Do some example work typical of what you'd be using the database
for. Then stop postgresql.
6. There will be a bunch of "avc: denied" messages in /var/log/messages
(or /var/log/audit/audit.log if auditd is running). Post the ones from
after the time you noted in step 4. From that it should be possible to
make a local policy module that will fix the SELinux problems and enable
you to run in enforcing mode again.
Setting SELinux into Permissive mode produces no "avc: anything"
messages in /var/log/messages. (Audit is not installed on my server.)
Switching back to Enforcing mode produces a bunch of audit messages, but
none while I'm starting, stopping, or using the database.
In Enforcing mode, failed attempts to start postgresql (because
postgresql is not excluded from SELinux policy) also produce no audit
messages.
Hmmmm...
3:34 a.m.
On Fri, 2006-05-26 at 15:24 -0700, Alan M. Evans wrote:
On Fri, 2006-05-26 at 02:28, Paul Howarth wrote:
> Alan M. Evans wrote:
> > On Wed, 2006-05-24 at 02:31, Paul Howarth wrote:
> >> Alan M. Evans wrote:
> >>> On Tue, 2006-05-23 at 12:05, Andreas Roth wrote:
> >>>> i had the same problem on my FC4 system. The problem is caused by
SELinux. You
> >>>> can just disable SELinux on the whole system or disable SELinux for
> >>>> postgresql.
> >>>> The proper way would be to set the correct security contexts to
> >>>> the /home/pgsql directory (using ls -Z and chcon). I haven't
tried this, but
> >>>> AFAIK it should work.
> >>> Thanks. Disabling SELinux for postgresql allowed service startup.
> >> I hope you used permissive mode rather than fully disabling SELinux.
> >> Otherwise, you'll be in for a long wait whilst your whole system is
> >> relabelled if you re-enabled SELinux.
> >
> > Well, disabled only for postgresql, as per the checkbox in
> > system-config-securitylevel. I don't think this will be a problem at
> > present -- there's nothing on the system worth compromising. And the
> > firewall should prevent the outside world accessing the database
> > directly. Nothing on the webserver exposes the database yet.
> >
> > This thread is about me trying to understand and setup the security
> > properly so that the server can one day safely face the world.
> >
> >>> Although I feel a bit creepy about disabling security in order to get
> >>> something working. Kind of like leaving one particular door unlocked
so
> >>> the janitor can get in...
> >> Yes, I agree.
> >>
> >>> I jacked around with the file security contexts with no luck. I hold
> >>> onto the hope that this can be made to work: SELinux and postgresql
> >>> living in harmony. Does anyone have a pointer to a crash course in
> >>> configuring SELinux security contexts?
> >> Compare the file contexts of the default location for the files with the
> >> file contexts you have in your new location.
> >>
> >> $ ls -lZa /home/pgsql
> >>
> >> Repeat for the default locations of everything you moved. Post the
> >> output you get.
> >
> > [root@citadel ~]# ls -lZa /home/pgsql
> > drwx--x--x postgres postgres system_u:object_r:user_home_dir_t .
> > drwxr-xr-x root root system_u:object_r:home_root_t ..
> > drwx------ postgres postgres system_u:object_r:postgresql_db_t data
> > -rw------- postgres postgres system_u:object_r:postgresql_log_t
> > pgstartup.log
> > [root@citadel ~]# ls -lZa /var/lib/pgsql
> > drwx------ postgres postgres system_u:object_r:var_lib_t .
> > drwxr-xr-x root root system_u:object_r:var_lib_t ..
> > drwx------ postgres postgres system_u:object_r:var_lib_t backups
> > drwx------ postgres postgres system_u:object_r:postgresql_db_t data
> > -rw------- postgres postgres system_u:object_r:postgresql_log_t
> > pgstartup.log
> > [root@citadel ~]#
> >
> > The security contexts and file permissions/ownerships are identical for
> > everything in the data directory. I even tried moving the /var/lib/pgsql
> > directory into home to be supremely certain that the contexts were the
> > same. No joy.
> >
> > At one time or another, I set /home/pgsql to the var_lib_t context (and
> > I think /home as well) in a desperate act of, "Can I get it to work at
> > all?" Still didn't work, although I don't feel like it was the
correct
> > solution anyway.
>
> It's a sensible thing to try, but not really the right one as you say.
>
> >> An alternative approach that often works is to bind mount the directory
> >> you want to use for your database/webserver/whatever to the default
> >> location and then use restorecon to fix the contexts.
> >
> > I don't exactly understand how this would differ substantially from
> > moving the original directory to the new parent, as I did.
> >
> > But that's not surprising. I clearly don't understand a lot. I'm
trying,
> > and I really want to do (and understand) the correct and proper method.
> > One would have thought that simply moving the DB data directory would be
> > a pretty common scenario, but it seems that SELinux makes this a
> > complicated task.
>
> One of the complications is that an application might try
> reading/searching a parent directory of where its files live. If you've
> moved its files to live under /home, this is likely to be denied because
> most daemons don't need to read/search home directories
> (user_home_dir_t) and so don't have the rights under policy to do that.
> Clearly this isn't the actual problem you've had because of what you've
> described earlier, but it could be similar.
>
> What I suggest you do is:
>
> 1. Re-enable SELinux for postgresql.
> 2. Put SELinux in permissive mode rather than enforcing.
> 3. Fix all of the file context labels so that they're appropriate (I
> think this may already be the case judging from what you show above)
> 4. Make a note of the time.
> 5. Start postgresql. It should work because SELinux is in permissive
> mode. Do some example work typical of what you'd be using the database
> for. Then stop postgresql.
> 6. There will be a bunch of "avc: denied" messages in /var/log/messages
> (or /var/log/audit/audit.log if auditd is running). Post the ones from
> after the time you noted in step 4. From that it should be possible to
> make a local policy module that will fix the SELinux problems and enable
> you to run in enforcing mode again.
Setting SELinux into Permissive mode produces no "avc: anything"
messages in /var/log/messages. (Audit is not installed on my server.)
Switching back to Enforcing mode produces a bunch of audit messages, but
none while I'm starting, stopping, or using the database.
In Enforcing mode, failed attempts to start postgresql (because
postgresql is not excluded from SELinux policy) also produce no audit
messages.
This is very strange. Some (expected and normally harmless) denials are
"dontaudit-ed" in policy so they don't fill up logs. These can be logged
if you do:
# emodule -b /usr/share/selinux/targeted/enableaudit.pp
To revert this, do:
# semodule -b /usr/share/selinux/targeted/base.pp
I curious about the audit messages you are seeing though. Could you post
a few samples (not relating to "hal", as I think they're more expected).
Paul.
10:18 a.m.
On Sat, 2006-05-27 at 01:34, Paul Howarth wrote:
On Fri, 2006-05-26 at 15:24 -0700, Alan M. Evans wrote:
> On Fri, 2006-05-26 at 02:28, Paul Howarth wrote:
> > Alan M. Evans wrote:
> > > On Wed, 2006-05-24 at 02:31, Paul Howarth wrote:
> > >> Alan M. Evans wrote:
> > >>> On Tue, 2006-05-23 at 12:05, Andreas Roth wrote:
> > >>>> i had the same problem on my FC4 system. The problem is caused
by SELinux. You
> > >>>> can just disable SELinux on the whole system or disable
SELinux for
> > >>>> postgresql.
> > >>>> The proper way would be to set the correct security contexts
to
> > >>>> the /home/pgsql directory (using ls -Z and chcon). I
haven't tried this, but
> > >>>> AFAIK it should work.
> > >>> Thanks. Disabling SELinux for postgresql allowed service startup.
> > >> I hope you used permissive mode rather than fully disabling SELinux.
> > >> Otherwise, you'll be in for a long wait whilst your whole system
is
> > >> relabelled if you re-enabled SELinux.
> > >
> > > Well, disabled only for postgresql, as per the checkbox in
> > > system-config-securitylevel. I don't think this will be a problem at
> > > present -- there's nothing on the system worth compromising. And the
> > > firewall should prevent the outside world accessing the database
> > > directly. Nothing on the webserver exposes the database yet.
> > >
> > > This thread is about me trying to understand and setup the security
> > > properly so that the server can one day safely face the world.
> > >
> > >>> Although I feel a bit creepy about disabling security in order to
get
> > >>> something working. Kind of like leaving one particular door
unlocked so
> > >>> the janitor can get in...
> > >> Yes, I agree.
> > >>
> > >>> I jacked around with the file security contexts with no luck. I
hold
> > >>> onto the hope that this can be made to work: SELinux and
postgresql
> > >>> living in harmony. Does anyone have a pointer to a crash course
in
> > >>> configuring SELinux security contexts?
> > >> Compare the file contexts of the default location for the files with
the
> > >> file contexts you have in your new location.
> > >>
> > >> $ ls -lZa /home/pgsql
> > >>
> > >> Repeat for the default locations of everything you moved. Post the
> > >> output you get.
> > >
> > > [root@citadel ~]# ls -lZa /home/pgsql
> > > drwx--x--x postgres postgres system_u:object_r:user_home_dir_t .
> > > drwxr-xr-x root root system_u:object_r:home_root_t ..
> > > drwx------ postgres postgres system_u:object_r:postgresql_db_t data
> > > -rw------- postgres postgres system_u:object_r:postgresql_log_t
> > > pgstartup.log
> > > [root@citadel ~]# ls -lZa /var/lib/pgsql
> > > drwx------ postgres postgres system_u:object_r:var_lib_t .
> > > drwxr-xr-x root root system_u:object_r:var_lib_t ..
> > > drwx------ postgres postgres system_u:object_r:var_lib_t backups
> > > drwx------ postgres postgres system_u:object_r:postgresql_db_t data
> > > -rw------- postgres postgres system_u:object_r:postgresql_log_t
> > > pgstartup.log
> > > [root@citadel ~]#
> > >
> > > The security contexts and file permissions/ownerships are identical for
> > > everything in the data directory. I even tried moving the /var/lib/pgsql
> > > directory into home to be supremely certain that the contexts were the
> > > same. No joy.
> > >
> > > At one time or another, I set /home/pgsql to the var_lib_t context (and
> > > I think /home as well) in a desperate act of, "Can I get it to work
at
> > > all?" Still didn't work, although I don't feel like it was
the correct
> > > solution anyway.
> >
> > It's a sensible thing to try, but not really the right one as you say.
> >
> > >> An alternative approach that often works is to bind mount the
directory
> > >> you want to use for your database/webserver/whatever to the default
> > >> location and then use restorecon to fix the contexts.
> > >
> > > I don't exactly understand how this would differ substantially from
> > > moving the original directory to the new parent, as I did.
> > >
> > > But that's not surprising. I clearly don't understand a lot.
I'm trying,
> > > and I really want to do (and understand) the correct and proper method.
> > > One would have thought that simply moving the DB data directory would be
> > > a pretty common scenario, but it seems that SELinux makes this a
> > > complicated task.
> >
> > One of the complications is that an application might try
> > reading/searching a parent directory of where its files live. If you've
> > moved its files to live under /home, this is likely to be denied because
> > most daemons don't need to read/search home directories
> > (user_home_dir_t) and so don't have the rights under policy to do that.
> > Clearly this isn't the actual problem you've had because of what
you've
> > described earlier, but it could be similar.
> >
> > What I suggest you do is:
> >
> > 1. Re-enable SELinux for postgresql.
> > 2. Put SELinux in permissive mode rather than enforcing.
> > 3. Fix all of the file context labels so that they're appropriate (I
> > think this may already be the case judging from what you show above)
> > 4. Make a note of the time.
> > 5. Start postgresql. It should work because SELinux is in permissive
> > mode. Do some example work typical of what you'd be using the database
> > for. Then stop postgresql.
> > 6. There will be a bunch of "avc: denied" messages in
/var/log/messages
> > (or /var/log/audit/audit.log if auditd is running). Post the ones from
> > after the time you noted in step 4. From that it should be possible to
> > make a local policy module that will fix the SELinux problems and enable
> > you to run in enforcing mode again.
>
> Setting SELinux into Permissive mode produces no "avc: anything"
> messages in /var/log/messages. (Audit is not installed on my server.)
> Switching back to Enforcing mode produces a bunch of audit messages, but
> none while I'm starting, stopping, or using the database.
>
> In Enforcing mode, failed attempts to start postgresql (because
> postgresql is not excluded from SELinux policy) also produce no audit
> messages.
This is very strange. Some (expected and normally harmless) denials are
"dontaudit-ed" in policy so they don't fill up logs. These can be logged
if you do:
# emodule -b /usr/share/selinux/targeted/enableaudit.pp
Ok. Did this. SELinux set to Enforcing, not excluding postgresql. Tried
starting postgresql, got one message:
May 30 08:07:51 citadel kernel: audit(1149001671.780:351): avc: denied
{ search } for pid=2403 comm="postmaster" name="/" dev=hda3 ino=2
scontext=root:system_r:postgresql_t:s0
tcontext=system_u:object_r:home_root_t:s0 tclass=dir
I get these again after setting policy to Permissive and attempting
(successfully) to start the service:
May 30 08:13:52 citadel kernel: audit(1149002032.907:352): avc:
granted { setenforce } for pid=2441 comm="setenforce"
scontext=system_u:system_r:unconfined_t:s0
tcontext=system_u:object_r:security_t:s0 tclass=security
May 30 08:14:01 citadel kernel: audit(1149002041.671:353): avc: denied
{ search } for pid=2475 comm="postmaster" name="/" dev=hda3 ino=2
scontext=root:system_r:postgresql_t:s0
tcontext=system_u:object_r:home_root_t:s0 tclass=dir
May 30 08:14:01 citadel kernel: audit(1149002041.671:354): avc: denied
{ search } for pid=2475 comm="postmaster" name="pgsql" dev=hda3
ino=3568225 scontext=root:system_r:postgresql_t:s0
tcontext=system_u:object_r:user_home_dir_t:s0 tclass=dir
May 30 08:14:02 citadel kernel: audit(1149002042.224:355): avc: denied
{ search } for pid=2475 comm="postmaster" name="/" dev=hda3 ino=2
scontext=root:system_r:postgresql_t:s0
tcontext=system_u:object_r:home_root_t:s0 tclass=dir
To revert this, do:
# semodule -b /usr/share/selinux/targeted/base.pp
I curious about the audit messages you are seeing though. Could you post
a few samples (not relating to "hal", as I think they're more expected).
There are many, mostly the same. And they don't (to me) seem related
specifically to the DB. If you like, I could post a copy of my messages
file to some convenient web location for you to peruse.
Thank you so much for your patience and continued help!
-Alan
11:10 a.m.
Alan M. Evans wrote:
On Sat, 2006-05-27 at 01:34, Paul Howarth wrote:
> On Fri, 2006-05-26 at 15:24 -0700, Alan M. Evans wrote:
>> On Fri, 2006-05-26 at 02:28, Paul Howarth wrote:
>>> Alan M. Evans wrote:
>>>> On Wed, 2006-05-24 at 02:31, Paul Howarth wrote:
>>>>> Alan M. Evans wrote:
>>>>>> On Tue, 2006-05-23 at 12:05, Andreas Roth wrote:
>>>>>>> i had the same problem on my FC4 system. The problem is
caused by SELinux. You
>>>>>>> can just disable SELinux on the whole system or disable
SELinux for
>>>>>>> postgresql.
>>>>>>> The proper way would be to set the correct security contexts
to
>>>>>>> the /home/pgsql directory (using ls -Z and chcon). I
haven't tried this, but
>>>>>>> AFAIK it should work.
>>>>>> Thanks. Disabling SELinux for postgresql allowed service
startup.
>>>>> I hope you used permissive mode rather than fully disabling SELinux.
>>>>> Otherwise, you'll be in for a long wait whilst your whole system
is
>>>>> relabelled if you re-enabled SELinux.
>>>> Well, disabled only for postgresql, as per the checkbox in
>>>> system-config-securitylevel. I don't think this will be a problem at
>>>> present -- there's nothing on the system worth compromising. And the
>>>> firewall should prevent the outside world accessing the database
>>>> directly. Nothing on the webserver exposes the database yet.
>>>>
>>>> This thread is about me trying to understand and setup the security
>>>> properly so that the server can one day safely face the world.
>>>>
>>>>>> Although I feel a bit creepy about disabling security in order to
get
>>>>>> something working. Kind of like leaving one particular door
unlocked so
>>>>>> the janitor can get in...
>>>>> Yes, I agree.
>>>>>
>>>>>> I jacked around with the file security contexts with no luck. I
hold
>>>>>> onto the hope that this can be made to work: SELinux and
postgresql
>>>>>> living in harmony. Does anyone have a pointer to a crash course
in
>>>>>> configuring SELinux security contexts?
>>>>> Compare the file contexts of the default location for the files with
the
>>>>> file contexts you have in your new location.
>>>>>
>>>>> $ ls -lZa /home/pgsql
>>>>>
>>>>> Repeat for the default locations of everything you moved. Post the
>>>>> output you get.
>>>> [root@citadel ~]# ls -lZa /home/pgsql
>>>> drwx--x--x postgres postgres system_u:object_r:user_home_dir_t .
>>>> drwxr-xr-x root root system_u:object_r:home_root_t ..
>>>> drwx------ postgres postgres system_u:object_r:postgresql_db_t data
>>>> -rw------- postgres postgres system_u:object_r:postgresql_log_t
>>>> pgstartup.log
>>>> [root@citadel ~]# ls -lZa /var/lib/pgsql
>>>> drwx------ postgres postgres system_u:object_r:var_lib_t .
>>>> drwxr-xr-x root root system_u:object_r:var_lib_t ..
>>>> drwx------ postgres postgres system_u:object_r:var_lib_t backups
>>>> drwx------ postgres postgres system_u:object_r:postgresql_db_t data
>>>> -rw------- postgres postgres system_u:object_r:postgresql_log_t
>>>> pgstartup.log
>>>> [root@citadel ~]#
...
>>> What I suggest you do is:
>>>
>>> 1. Re-enable SELinux for postgresql.
>>> 2. Put SELinux in permissive mode rather than enforcing.
>>> 3. Fix all of the file context labels so that they're appropriate (I
>>> think this may already be the case judging from what you show above)
>>> 4. Make a note of the time.
>>> 5. Start postgresql. It should work because SELinux is in permissive
>>> mode. Do some example work typical of what you'd be using the database
>>> for. Then stop postgresql.
>>> 6. There will be a bunch of "avc: denied" messages in
/var/log/messages
>>> (or /var/log/audit/audit.log if auditd is running). Post the ones from
>>> after the time you noted in step 4. From that it should be possible to
>>> make a local policy module that will fix the SELinux problems and enable
>>> you to run in enforcing mode again.
>> Setting SELinux into Permissive mode produces no "avc: anything"
>> messages in /var/log/messages. (Audit is not installed on my server.)
>> Switching back to Enforcing mode produces a bunch of audit messages, but
>> none while I'm starting, stopping, or using the database.
>>
>> In Enforcing mode, failed attempts to start postgresql (because
>> postgresql is not excluded from SELinux policy) also produce no audit
>> messages.
> This is very strange. Some (expected and normally harmless) denials are
> "dontaudit-ed" in policy so they don't fill up logs. These can be
logged
> if you do:
>
> # emodule -b /usr/share/selinux/targeted/enableaudit.pp
Ok. Did this. SELinux set to Enforcing, not excluding postgresql. Tried
starting postgresql, got one message:
May 30 08:07:51 citadel kernel: audit(1149001671.780:351): avc: denied
{ search } for pid=2403 comm="postmaster" name="/" dev=hda3 ino=2
scontext=root:system_r:postgresql_t:s0
tcontext=system_u:object_r:home_root_t:s0 tclass=dir
I think this is postgresql denied being able to read directory /home
(/dev/hda3?). This one is to be expected really, and will need to be
allowed for using a local policy tweak.
I get these again after setting policy to Permissive and attempting
(successfully) to start the service:
May 30 08:13:52 citadel kernel: audit(1149002032.907:352): avc:
granted { setenforce } for pid=2441 comm="setenforce"
scontext=system_u:system_r:unconfined_t:s0
tcontext=system_u:object_r:security_t:s0 tclass=security
That's you being granted permission to set permissive mode.
May 30 08:14:01 citadel kernel: audit(1149002041.671:353): avc:
denied
{ search } for pid=2475 comm="postmaster" name="/" dev=hda3 ino=2
scontext=root:system_r:postgresql_t:s0
tcontext=system_u:object_r:home_root_t:s0 tclass=dir
That's the same one as above.
May 30 08:14:01 citadel kernel: audit(1149002041.671:354): avc:
denied
{ search } for pid=2475 comm="postmaster" name="pgsql" dev=hda3
ino=3568225 scontext=root:system_r:postgresql_t:s0
tcontext=system_u:object_r:user_home_dir_t:s0 tclass=dir
That's postgresql being denied access to read directory /home/pgsql,
which should probably have context var_lib_t rather than user_home_dir_t
in order to line up with the original location.
May 30 08:14:02 citadel kernel: audit(1149002042.224:355): avc:
denied
{ search } for pid=2475 comm="postmaster" name="/" dev=hda3 ino=2
scontext=root:system_r:postgresql_t:s0
tcontext=system_u:object_r:home_root_t:s0 tclass=dir
That's the same as the first one again.
If that's all you have, it shouldn't be difficult to fix.
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 postgresql.te with this content:
module postgresql 0.1;
require {
class dir search;
class lnk_file read;
type home_root_t;
type postgresql_t;
type var_lib_t;
};
# Allow postgresql to read /var/lib/pgsql -> /home/pgsql symlink
# if present
allow postgresql_t var_lib_t:lnk_file read;
# Allow postgresql to search directory /home
allow postgresql_t home_root_t:dir search;
2. Create a file postgresql.fc with this content:
/home/pgsql -d
gen_context(system_u:object_r:var_lib_t,s0)
/home/pgsql/data(/.*)?
gen_context(system_u:object_r:postgresql_db_t,s0)
/home/pgsql/pgstartup.log --
gen_context(system_u:object_r:postgresql_log_t,s0)
(that's three long lines)
3. Create an empty postgresql.if file:
# touch postgresql.if
4. Build the policy module
# make
Install your new policy module:
# semodule -i postgresql.pp
Fix file contexts:
# restorecon -Rv /home/pgsql
Hopefully that should get you going in enforcing mode.
Paul.
12:40 p.m.
On Tue, 2006-05-30 at 09:10, Paul Howarth wrote:
[ ... ]
If that's all you have, it shouldn't be difficult to fix.
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 postgresql.te with this content:
module postgresql 0.1;
require {
class dir search;
class lnk_file read;
type home_root_t;
type postgresql_t;
type var_lib_t;
};
# Allow postgresql to read /var/lib/pgsql -> /home/pgsql symlink
# if present
allow postgresql_t var_lib_t:lnk_file read;
# Allow postgresql to search directory /home
allow postgresql_t home_root_t:dir search;
2. Create a file postgresql.fc with this content:
/home/pgsql -d
gen_context(system_u:object_r:var_lib_t,s0)
/home/pgsql/data(/.*)?
gen_context(system_u:object_r:postgresql_db_t,s0)
/home/pgsql/pgstartup.log --
gen_context(system_u:object_r:postgresql_log_t,s0)
(that's three long lines)
3. Create an empty postgresql.if file:
# touch postgresql.if
4. Build the policy module
# make
Install your new policy module:
# semodule -i postgresql.pp
Fix file contexts:
# restorecon -Rv /home/pgsql
Hopefully that should get you going in enforcing mode.
Well, that restorecon set all the contexts back to user_home_t. Ugh.
After recursively setting the data directory to postgresql_db_t and the
logfile to postgresql_log_t, service starts up without complaint. So
then:
postgresql started... check
database located under /home/pgsql... check
SELinux enforcing... yep
postgresql service not excluded... yes
read and write data to db... YES!
Excellent. I presume I should keep these SELinux policy source files in
a safe place in case this configuration is required again.
Thank you so much for your assistance! I have one final question. Do you
have any recommendations for decent documentation on SELinux
administration? Online is alright, but book recommendations are
perfectly welcome.
I hope to avoid having to go through this in the future. My goal is
really to understand the process. Right now, all I can do is describe
the problem and hope someone can walk me through the solution as you
have done. (I learn well from examples, so I know much more now that
I've at least gone through it.)
-Alan
12:48 p.m.
Alan M. Evans wrote:
On Tue, 2006-05-30 at 09:10, Paul Howarth wrote:
[ ... ]
> If that's all you have, it shouldn't be difficult to fix.
>
> 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 postgresql.te with this content:
>
> module postgresql 0.1;
>
> require {
> class dir search;
> class lnk_file read;
>
> type home_root_t;
> type postgresql_t;
> type var_lib_t;
> };
>
> # Allow postgresql to read /var/lib/pgsql -> /home/pgsql symlink
> # if present
> allow postgresql_t var_lib_t:lnk_file read;
>
> # Allow postgresql to search directory /home
> allow postgresql_t home_root_t:dir search;
>
> 2. Create a file postgresql.fc with this content:
>
> /home/pgsql -d
> gen_context(system_u:object_r:var_lib_t,s0)
> /home/pgsql/data(/.*)?
> gen_context(system_u:object_r:postgresql_db_t,s0)
> /home/pgsql/pgstartup.log --
> gen_context(system_u:object_r:postgresql_log_t,s0)
>
> (that's three long lines)
>
> 3. Create an empty postgresql.if file:
>
> # touch postgresql.if
>
> 4. Build the policy module
>
> # make
>
> Install your new policy module:
>
> # semodule -i postgresql.pp
>
> Fix file contexts:
>
> # restorecon -Rv /home/pgsql
>
> Hopefully that should get you going in enforcing mode.
Well, that restorecon set all the contexts back to user_home_t. Ugh.
Ugh indeed. My fix is incomplete. Can you post the output of:
# semanage fcontext -l | grep pgsql
I trust that /home/pgsql is not some user's home directory?
After recursively setting the data directory to postgresql_db_t and
the
logfile to postgresql_log_t, service starts up without complaint. So
then:
postgresql started... check
database located under /home/pgsql... check
SELinux enforcing... yep
postgresql service not excluded... yes
read and write data to db... YES!
Excellent. I presume I should keep these SELinux policy source files in
a safe place in case this configuration is required again.
I'd keep them around for reference purposes but the policy module should
survive reboots and base policy updates.
Thank you so much for your assistance! I have one final question. Do
you
have any recommendations for decent documentation on SELinux
administration? Online is alright, but book recommendations are
perfectly welcome.
Not really. I think it's too much of a moving target at the moment to
find anything that's up to date in print.
I hope to avoid having to go through this in the future. My goal is
really to understand the process. Right now, all I can do is describe
the problem and hope someone can walk me through the solution as you
have done. (I learn well from examples, so I know much more now that
I've at least gone through it.)
The way I learned about it was by reading the FC3 SELinux/Apache FAQ
(http://fedora.redhat.com/docs/selinux-apache-fc3/), which is a bit out
of date now, particularly regarding policy customization, hanging out on
fedora-selinux-list, and getting my own systems working to my own
satisfaction in enforcing mode.
The online documentation is getting better, and a good place to start is
probably: http://fedoraproject.org/wiki/SELinux
Paul.
1:21 p.m.
On Tue, 2006-05-30 at 10:48, Paul Howarth wrote:
Alan M. Evans wrote:
> On Tue, 2006-05-30 at 09:10, Paul Howarth wrote:
> [ ... ]
>> If that's all you have, it shouldn't be difficult to fix.
>>
>> 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 postgresql.te with this content:
>>
>> module postgresql 0.1;
>>
>> require {
>> class dir search;
>> class lnk_file read;
>>
>> type home_root_t;
>> type postgresql_t;
>> type var_lib_t;
>> };
>>
>> # Allow postgresql to read /var/lib/pgsql -> /home/pgsql symlink
>> # if present
>> allow postgresql_t var_lib_t:lnk_file read;
>>
>> # Allow postgresql to search directory /home
>> allow postgresql_t home_root_t:dir search;
>>
>> 2. Create a file postgresql.fc with this content:
>>
>> /home/pgsql -d
>> gen_context(system_u:object_r:var_lib_t,s0)
>> /home/pgsql/data(/.*)?
>> gen_context(system_u:object_r:postgresql_db_t,s0)
>> /home/pgsql/pgstartup.log --
>> gen_context(system_u:object_r:postgresql_log_t,s0)
>>
>> (that's three long lines)
>>
>> 3. Create an empty postgresql.if file:
>>
>> # touch postgresql.if
>>
>> 4. Build the policy module
>>
>> # make
>>
>> Install your new policy module:
>>
>> # semodule -i postgresql.pp
>>
>> Fix file contexts:
>>
>> # restorecon -Rv /home/pgsql
>>
>> Hopefully that should get you going in enforcing mode.
>
> Well, that restorecon set all the contexts back to user_home_t. Ugh.
Ugh indeed. My fix is incomplete. Can you post the output of:
# semanage fcontext -l | grep pgsql
Sure:
# semanage fcontext -l | grep pgsql
/usr/lib/pgsql/test/regress/pg_regress regular file
system_u:object_r:postgresql_exec_t:s0
/var/lib/pgsql/data(/.*)? all files
system_u:object_r:postgresql_db_t:s0
/home/pgsql/pgstartup.log regular file
system_u:object_r:postgresql_log_t:s0
/var/lib/pgsql/pgstartup.log all files
system_u:object_r:postgresql_log_t:s0
/usr/share/jonas/pgsql(/.*)? all files
system_u:object_r:postgresql_db_t:s0
/home/pgsql directory
system_u:object_r:var_lib_t:s0
/home/pgsql/data(/.*)? all files
system_u:object_r:postgresql_db_t:s0
/usr/lib/pgsql/test/regress/.*\.sh regular file
system_u:object_r:bin_t:s0
/usr/lib/pgsql/test/regres(/.*)? all files
system_u:object_r:postgresql_db_t:s0
I trust that /home/pgsql is not some user's home directory?
That is correct.
> After recursively setting the data directory to postgresql_db_t
and the
> logfile to postgresql_log_t, service starts up without complaint. So
> then:
>
> postgresql started... check
> database located under /home/pgsql... check
> SELinux enforcing... yep
> postgresql service not excluded... yes
> read and write data to db... YES!
>
> Excellent. I presume I should keep these SELinux policy source files in
> a safe place in case this configuration is required again.
I'd keep them around for reference purposes but the policy module should
survive reboots and base policy updates.
> Thank you so much for your assistance! I have one final question. Do you
> have any recommendations for decent documentation on SELinux
> administration? Online is alright, but book recommendations are
> perfectly welcome.
Not really. I think it's too much of a moving target at the moment to
find anything that's up to date in print.
> I hope to avoid having to go through this in the future. My goal is
> really to understand the process. Right now, all I can do is describe
> the problem and hope someone can walk me through the solution as you
> have done. (I learn well from examples, so I know much more now that
> I've at least gone through it.)
The way I learned about it was by reading the FC3 SELinux/Apache FAQ
(http://fedora.redhat.com/docs/selinux-apache-fc3/), which is a bit out
of date now, particularly regarding policy customization, hanging out on
fedora-selinux-list, and getting my own systems working to my own
satisfaction in enforcing mode.
The online documentation is getting better, and a good place to start is
probably: http://fedoraproject.org/wiki/SELinux
I'll have a look at those, and probably lurk the fedora-selinux-list for
awhile. You've been very helpful.
-Alan
12:19 p.m.
Alan M. Evans wrote:
On Tue, 2006-05-30 at 10:48, Paul Howarth wrote:
> Alan M. Evans wrote:
>> On Tue, 2006-05-30 at 09:10, Paul Howarth wrote:
>> [ ... ]
>>> If that's all you have, it shouldn't be difficult to fix.
>>>
>>> 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 postgresql.te with this content:
>>>
>>> module postgresql 0.1;
>>>
>>> require {
>>> class dir search;
>>> class lnk_file read;
>>>
>>> type home_root_t;
>>> type postgresql_t;
>>> type var_lib_t;
>>> };
>>>
>>> # Allow postgresql to read /var/lib/pgsql -> /home/pgsql symlink
>>> # if present
>>> allow postgresql_t var_lib_t:lnk_file read;
>>>
>>> # Allow postgresql to search directory /home
>>> allow postgresql_t home_root_t:dir search;
>>>
>>> 2. Create a file postgresql.fc with this content:
>>>
>>> /home/pgsql -d
>>> gen_context(system_u:object_r:var_lib_t,s0)
>>> /home/pgsql/data(/.*)?
>>> gen_context(system_u:object_r:postgresql_db_t,s0)
>>> /home/pgsql/pgstartup.log --
>>> gen_context(system_u:object_r:postgresql_log_t,s0)
>>>
>>> (that's three long lines)
>>>
>>> 3. Create an empty postgresql.if file:
>>>
>>> # touch postgresql.if
>>>
>>> 4. Build the policy module
>>>
>>> # make
>>>
>>> Install your new policy module:
>>>
>>> # semodule -i postgresql.pp
>>>
>>> Fix file contexts:
>>>
>>> # restorecon -Rv /home/pgsql
>>>
>>> Hopefully that should get you going in enforcing mode.
>> Well, that restorecon set all the contexts back to user_home_t. Ugh.
> Ugh indeed. My fix is incomplete. Can you post the output of:
> # semanage fcontext -l | grep pgsql
Sure:
# semanage fcontext -l | grep pgsql
/usr/lib/pgsql/test/regress/pg_regress regular file
system_u:object_r:postgresql_exec_t:s0
/var/lib/pgsql/data(/.*)? all files
system_u:object_r:postgresql_db_t:s0
/home/pgsql/pgstartup.log regular file
system_u:object_r:postgresql_log_t:s0
/var/lib/pgsql/pgstartup.log all files
system_u:object_r:postgresql_log_t:s0
/usr/share/jonas/pgsql(/.*)? all files
system_u:object_r:postgresql_db_t:s0
/home/pgsql directory
system_u:object_r:var_lib_t:s0
/home/pgsql/data(/.*)? all files
system_u:object_r:postgresql_db_t:s0
/usr/lib/pgsql/test/regress/.*\.sh regular file
system_u:object_r:bin_t:s0
/usr/lib/pgsql/test/regres(/.*)? all files
system_u:object_r:postgresql_db_t:s0
> I trust that /home/pgsql is not some user's home directory?
That is correct.
It appears that there is no easy fix for this problem, other than moving
the data somewhere other than under /home:
http://www.redhat.com/archives/fedora-selinux-list/2006-May/msg00253.html
Paul.
2:12 p.m.
On Wed, 2006-05-31 at 10:19, Paul Howarth wrote:
It appears that there is no easy fix for this problem, other than
moving
the data somewhere other than under /home:
http://www.redhat.com/archives/fedora-selinux-list/2006-May/msg00253.html
That's a pity. As I said before, /home is convenient for me since that
partition is large and won't ever be formatted during future upgrades or
installs. /home/pgsql seemed obvious to me since both the database and
the home directories share these requirements.
In any case, in your reply to the message linked above, you say:
If it was me I'd just bind mount /home/pgsql on /var/lib/pgsql
and there wouldn't be an issue...
And so I wonder: How does bind-mounting help me as regards default
contexts?
If I place data in /home/pgsql and bind-mount /var/lib/pgsql, then what
is the default context for pgsql? It depends on where restorecon was
run. If "restorecon -R /home" then pgsql will be set to the wrong
context; if "restorecon -R /var/lib" then it will be correct. And if,
for some reason, the entire filesystem gets relabelled, how do I know
which one it will get? I don't see what bind-mounting gains me anything
over my current predicament.
Finally, it's working for me now, thanks to you. I will leave it all as
is and lurk the selinux list and quietly learn. Perhaps a better
solution to the default context issue will be discovered or implemented.
And if I'm wrong about the bind-mounting thing then do explain, please!
6:37 a.m.
Alan M. Evans wrote:
On Wed, 2006-05-31 at 10:19, Paul Howarth wrote:
> It appears that there is no easy fix for this problem, other than moving
> the data somewhere other than under /home:
>
> http://www.redhat.com/archives/fedora-selinux-list/2006-May/msg00253.html
That's a pity. As I said before, /home is convenient for me since that
partition is large and won't ever be formatted during future upgrades or
installs. /home/pgsql seemed obvious to me since both the database and
the home directories share these requirements.
Another possibility you might consider (particularly if you have /home
on LVM) might be to shrink /home and use the released space for a
separate /srv filesystem, which you could manage in the same way as
/home, not formatting it during upgrades etc. Your database data could
then be put under /srv/pgsql (where it arguably should be by default in
the package) instead of /home/pgsql and there would be no issue with
home directory contexts.
In any case, in your reply to the message linked above, you say:
> If it was me I'd just bind mount /home/pgsql on /var/lib/pgsql
> and there wouldn't be an issue...
And so I wonder: How does bind-mounting help me as regards default
contexts?
If I place data in /home/pgsql and bind-mount /var/lib/pgsql, then what
is the default context for pgsql? It depends on where restorecon was
run. If "restorecon -R /home" then pgsql will be set to the wrong
context; if "restorecon -R /var/lib" then it will be correct. And if,
for some reason, the entire filesystem gets relabelled, how do I know
which one it will get? I don't see what bind-mounting gains me anything
over my current predicament.
You are right (and it illustrates an issue with path-based security). If
the system was relabelled, it'd be pot luck whether the /home/pgsql or
/var/lib/pgsql contexts were applied. The advantages of doing the bind
mount are:
1. No tweaks to policy are needed because everything is where it's
expected to be.
2. In the event of having to relabel the system and the contexts getting
screwed up, all of the different contexts can be restored in one go with
the single command "restorecon -Rv /var/lib/pgsql", as opposed to having
to do different chcon commands for each different context that's needed.
Finally, it's working for me now, thanks to you. I will leave it
all as
is and lurk the selinux list and quietly learn. Perhaps a better
solution to the default context issue will be discovered or implemented.
I've not given up on this yet; see fedora-selinux-list.
Paul.
11:16 a.m.
At 12:37 PM +0100 6/1/06, Paul Howarth wrote:
Alan M. Evans wrote:
...
> In any case, in your reply to the message linked above, you say:
>
>> If it was me I'd just bind mount /home/pgsql on /var/lib/pgsql
>> and there wouldn't be an issue...
>
> And so I wonder: How does bind-mounting help me as regards default
> contexts?
>
> If I place data in /home/pgsql and bind-mount /var/lib/pgsql, then what
> is the default context for pgsql? It depends on where restorecon was
> run. If "restorecon -R /home" then pgsql will be set to the wrong
> context; if "restorecon -R /var/lib" then it will be correct. And if,
> for some reason, the entire filesystem gets relabelled, how do I know
> which one it will get? I don't see what bind-mounting gains me anything
> over my current predicament.
You are right (and it illustrates an issue with path-based security). If
the system was relabelled, it'd be pot luck whether the /home/pgsql or
/var/lib/pgsql contexts were applied. The advantages of doing the bind
mount are:
1. No tweaks to policy are needed because everything is where it's
expected to be.
2. In the event of having to relabel the system and the contexts getting
screwed up, all of the different contexts can be restored in one go with
the single command "restorecon -Rv /var/lib/pgsql", as opposed to having
to do different chcon commands for each different context that's needed.
Would --move do what is needed? The space on /home would be used for the
dir /var/lib/pgsql, which would only be there, and not both places as with
--bind.
____________________________________________________________________
TonyN.:' <mailto:tonynelson@georgeanelson.com>
' <http://www.georgeanelson.com/>
11:35 a.m.
Tony Nelson wrote:
At 12:37 PM +0100 6/1/06, Paul Howarth wrote:
> Alan M. Evans wrote:
...
>> In any case, in your reply to the message linked above, you say:
>>
>>> If it was me I'd just bind mount /home/pgsql on /var/lib/pgsql
>>> and there wouldn't be an issue...
>> And so I wonder: How does bind-mounting help me as regards default
>> contexts?
>>
>> If I place data in /home/pgsql and bind-mount /var/lib/pgsql, then what
>> is the default context for pgsql? It depends on where restorecon was
>> run. If "restorecon -R /home" then pgsql will be set to the wrong
>> context; if "restorecon -R /var/lib" then it will be correct. And if,
>> for some reason, the entire filesystem gets relabelled, how do I know
>> which one it will get? I don't see what bind-mounting gains me anything
>> over my current predicament.
> You are right (and it illustrates an issue with path-based security). If
> the system was relabelled, it'd be pot luck whether the /home/pgsql or
> /var/lib/pgsql contexts were applied. The advantages of doing the bind
> mount are:
>
> 1. No tweaks to policy are needed because everything is where it's
> expected to be.
> 2. In the event of having to relabel the system and the contexts getting
> screwed up, all of the different contexts can be restored in one go with
> the single command "restorecon -Rv /var/lib/pgsql", as opposed to having
> to do different chcon commands for each different context that's needed.
Would --move do what is needed? The space on /home would be used for the
dir /var/lib/pgsql, which would only be there, and not both places as with
--bind.
That would be ideal but I've never got "mount --move" to work. Every
time I've tried it I get:
# mount --move /home/pgsql /var/lib/pgsql
mount: wrong fs type, bad option, bad superblock on /home/pgsql,
missing codepage or other error
In some cases useful info is found in syslog - try
dmesg | tail or so
Perhaps someone can tell me what I'm doing wrong?
Paul.
6559
days inactive
6568
days old
18 comments
5 participants
participants (5)
-
Alan M. Evans -
Andreas Roth -
Paul Howarth -
Tim -
Tony Nelson