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
--
fedora-list mailing list
fedora-list@xxxxxxxxxx
To unsubscribe: https://www.redhat.com/mailman/listinfo/fedora-list
