Bug 187744 - Postgresql initialization ignores selinux settings
Postgresql initialization ignores selinux settings
Status: CLOSED ERRATA
Product: Fedora
Classification: Fedora
Component: postgresql (Show other bugs)
rawhide
All Linux
medium Severity low
: ---
: ---
Assigned To: Tom Lane
David Lawrence
:
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2006-04-03 09:22 EDT by Philippe Rigault
Modified: 2013-07-02 23:09 EDT (History)
1 user (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2006-05-23 14:55:58 EDT
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)

  None (edit)
Description Philippe Rigault 2006-04-03 09:22:53 EDT
Description of problem: When postgresql starts for the first time, it creates 
$PGLOG and attemps to change its selinux context even tough selinux is set 
to 'disabled' (and therefore selinux related privileges should be ignored).


Version-Release number of selected component (if applicable): 
postgresql-8.1.3-1

How reproducible: Always


Steps to Reproduce:
1. Install FC5 with selinux set to disabled
2. Start postgresql

  
Actual results:
/usr/bin/chcon: can't apply partial context to unlabeled 
file /opt/pgsql/data/pgstartup.log
Starting postgresql service:                               [  OK  ]


Expected results:
Starting postgresql service:                               [  OK  ]


Additional info:
The test whether chcon should be applied is below:

<snip>
start(){
        PSQL_START=$"Starting ${NAME} service: "

        # Make sure startup-time log file is valid
        if [ ! -e "$PGLOG" -a ! -h "$PGLOG" ]
        then
                touch "$PGLOG" || exit 1
                chown postgres:postgres "$PGLOG"
                chmod go-rwx "$PGLOG"
                [ -x /usr/bin/chcon ] && /usr/bin/chcon -u system_u -r 
object_r -t postgresql_log_t "$PGLOG"
        fi
<snip>

The test should rather test whether selinux is enabled (for example looking 
in /etc/sysconfig/selinux)

Cheers.
Comment 1 Tom Lane 2006-04-03 09:55:01 EDT
Isn't this a strictly cosmetic problem?
Comment 2 Philippe Rigault 2006-04-03 10:08:51 EDT
> Isn't this a strictly cosmetic problem?
Yes, but some users get the feeling that something failed.
And maybe in the future something will use that return value, or perform more 
tasks that are selinux-related, so including the correct logic now is 
preparing for the future.

and who said cosmetics aren't important ;-)
Comment 3 Tom Lane 2006-04-03 10:19:36 EDT
Inspecting another package's config file sounds to me like a recipe for future
breakage, not "preparing for the future".

I'd be inclined to just add "2>/dev/null" to the command.
Comment 4 Philippe Rigault 2006-04-03 10:36:16 EDT
> Inspecting another package's config file sounds to me like a recipe
> for future breakage, not "preparing for the future".
Agreed, dynamically checking (i.e /proc), if possible, would be more 
appropriate. I don't know what /proc test would be the right one, though.

> I'd be inclined to just add "2>/dev/null" to the command.
That would be fine.
Comment 5 Tom Lane 2006-04-03 10:46:46 EDT
OK, adding to the to-do list ...
Comment 6 Tom Lane 2006-05-23 14:55:58 EDT
Done in today's releases.

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