Bug 746510 - SELinux is preventing /usr/bin/postgres from 'read' accesses on the lnk_file /var/lib/pgsql/data.
Summary: SELinux is preventing /usr/bin/postgres from 'read' accesses on the lnk_file ...
Keywords:
Status: CLOSED NOTABUG
Alias: None
Product: Fedora
Classification: Fedora
Component: selinux-policy
Version: 14
Hardware: x86_64
OS: Linux
unspecified
medium
Target Milestone: ---
Assignee: Miroslav Grepl
QA Contact: Fedora Extras Quality Assurance
URL:
Whiteboard: setroubleshoot_trace_hash:b7b4ecf1390...
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2011-10-16 18:36 UTC by Dale Snell
Modified: 2011-10-17 16:32 UTC (History)
3 users (show)

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Clone Of:
Environment:
Last Closed: 2011-10-17 06:56:52 UTC
Type: ---
Embargoed:


Attachments (Terms of Use)

Description Dale Snell 2011-10-16 18:36:39 UTC
SELinux is preventing /usr/bin/postgres from 'read' accesses on the lnk_file /var/lib/pgsql/data.

*****  Plugin restorecon (94.8 confidence) suggests  *************************

If you want to fix the label. 
/var/lib/pgsql/data default label should be postgresql_db_t.
Then you can run restorecon.
Do
# /sbin/restorecon -v /var/lib/pgsql/data

*****  Plugin catchall_labels (5.21 confidence) suggests  ********************

If you want to allow postgres to have read access on the data lnk_file
Then you need to change the label on /var/lib/pgsql/data
Do
# semanage fcontext -a -t FILE_TYPE '/var/lib/pgsql/data'
where FILE_TYPE is one of the following: etc_runtime_t, abrt_t, bin_t, selinux_config_t, cert_t, lib_t, root_t, usr_t, mail_spool_t, device_t, device_t, devlog_t, locale_t, etc_t, ld_so_t, proc_t, proc_t, postgresql_tmp_t, sysfs_t, textrel_shlib_t, postgresql_db_t, postgresql_t, postgresql_etc_t, rpm_script_tmp_t, postgresql_exec_t, udev_tbl_t. 
Then execute: 
restorecon -v '/var/lib/pgsql/data'


*****  Plugin catchall (1.44 confidence) suggests  ***************************

If you believe that postgres should be allowed read access on the data lnk_file by default.
Then you should report this as a bug.
You can generate a local policy module to allow this access.
Do
allow this access for now by executing:
# grep postmaster /var/log/audit/audit.log | audit2allow -M mypol
# semodule -i mypol.pp

Additional Information:
Source Context                unconfined_u:system_r:postgresql_t:s0
Target Context                unconfined_u:object_r:var_lib_t:s0
Target Objects                /var/lib/pgsql/data [ lnk_file ]
Source                        postmaster
Source Path                   /usr/bin/postgres
Port                          <Unknown>
Host                          (removed)
Source RPM Packages           postgresql-server-8.4.9-1.fc14
Target RPM Packages           postgresql-server-8.4.9-1.fc14
Policy RPM                    selinux-policy-3.9.7-44.fc14
Selinux Enabled               True
Policy Type                   targeted
Enforcing Mode                Enforcing
Host Name                     (removed)
Platform                      Linux (removed) 2.6.35.14-97.fc14.x86_64 #1 SMP Sat
                              Sep 17 00:15:37 UTC 2011 x86_64 x86_64
Alert Count                   4
First Seen                    Sat 15 Oct 2011 09:42:41 PM PDT
Last Seen                     Sat 15 Oct 2011 10:02:09 PM PDT
Local ID                      289e9818-5a63-4c58-90ea-105301bf119a

Raw Audit Messages
type=AVC msg=audit(1318741329.627:12252): avc:  denied  { read } for  pid=1771 comm="initdb" name="data" dev=dm-10 ino=132279 scontext=unconfined_u:system_r:postgresql_t:s0 tcontext=unconfined_u:object_r:var_lib_t:s0 tclass=lnk_file


type=SYSCALL msg=audit(1318741329.627:12252): arch=x86_64 syscall=open success=no exit=EACCES a0=244f800 a1=90800 a2=0 a3=8 items=0 ppid=1770 pid=1771 auid=500 uid=26 gid=26 euid=26 suid=26 fsuid=26 egid=26 sgid=26 fsgid=26 tty=(none) ses=919 comm=initdb exe=/usr/bin/initdb subj=unconfined_u:system_r:postgresql_t:s0 key=(null)

Hash: postmaster,postgresql_t,var_lib_t,lnk_file,read

audit2allow

#============= postgresql_t ==============
#!!!! This avc is allowed in the current policy

allow postgresql_t var_lib_t:lnk_file read;

audit2allow -R

#============= postgresql_t ==============
#!!!! This avc is allowed in the current policy

allow postgresql_t var_lib_t:lnk_file read;

Comment 1 Dale Snell 2011-10-16 19:08:00 UTC
Some additional information that you might find useful:

My PostgreSQL databases are on a separate partition, /srv/databases/PostgreSQL.  /var/lib/pgsql/data is a symbolic link to that location.

The problem showed up when I tried to do a "service postgresql initdb".  This failed with no diagnostic message.  (Now *THAT* is frustrating!)  To correct the error, I tried the first option SETroubleshoot presented, Plugin restorecon.  That ran with no trouble, and the ../PostgreSQL directory was labeled properly, which it hadn't been before.  So far, so good.  Unfortunately, I still couldn't initdb.  The second option, "Plugin catchall_labels", wanted to change the labeling of the link file proper.  This failed, since semanage followed the link to the destination directory.  So I was left with the final choice, "Plugin catchall", which worked.  I was able to initialize the database cluster and start PostgreSQL.  Yay!  :-)

Comment 2 Miroslav Grepl 2011-10-17 06:56:52 UTC
You can add the proper label for your link using

# chcon -h -t postgresql_db_t /var/lib/pgsql/data

Comment 3 Dale Snell 2011-10-17 16:09:04 UTC
(In reply to comment #2)
> You can add the proper label for your link using
> 
> # chcon -h -t postgresql_db_t /var/lib/pgsql/data

I did try that, actually.  chcon responded with "Permission Denied".  Thinking that was probably proper behavior, I let it go and tried the last option.  That worked, so I'm happy.

*sigh*  I just tried the command again.  It worked this time.  I don't know what I did wrong the first time, but this time the command worked like it was supposed to.  Oh well, PostgreSQL is working now, which was all I really wanted, so I'm not going to worry about it.  Thank you, Miroslav, for looking into this; I apologize for taking up your time.

Comment 4 Daniel Walsh 2011-10-17 16:12:51 UTC
Most likely you were not root when you executed the command the first time.

Comment 5 Dale Snell 2011-10-17 16:32:57 UTC
Probably.  I was doing things as root using sudo; it's quite possible I had forgotten to sudo that command.


Note You need to log in before you can comment on or make changes to this bug.