CentOS - May 2005 - PostgreSQL/SELinux Error - relation "pg_catalog.pg_user" does not exist

hello everyone,

i'm trying to run a postgresql service on my newly-installed centos4
box. i have been able to recreate my users, set up the permissions,
and restore the database dump. also, i can already log-in to my
databases.

there is, however, one annoying problem. whenever i type \du (or \d or
\l) on the psql prompt, i get the following error:

ERROR:  relation "pg_catalog.pg_user" does not exist

after some googling, i'm beginning to suspect that this is a SELinux
issue. i then try to disable SELinux on the postgresql daemon by
doing:

# setsebool postgresql_disable_trans true

that does not work unfortunately as i'm still stuck with the same error.

while i can definitely just disable SELinux on this box, i would want
a more elegant solution that solves this annoying problem. can anyone
help me on this?

thanks in advance!
matt

-- 
Stand before it and there is no beginning.
Follow it and there is no end.
Stay with the ancient Tao,
Move with the present.

Just turn off SELinux, it really is a complete pain.

I've managed to set up Linux and Unix boxes securely for years without 
all the SE Linux baggage.....

All it does is slow the machine down, and adds "bloat" to the OS...

P.


Matt Arnilo S. Baluyos (Mailing Lists) wrote:
>hello everyone,
>
>i'm trying to run a postgresql service on my newly-installed centos4
>box. i have been able to recreate my users, set up the permissions,
>and restore the database dump. also, i can already log-in to my
>databases.
>
>there is, however, one annoying problem. whenever i type \du (or \d or
>\l) on the psql prompt, i get the following error:
>
>ERROR:  relation "pg_catalog.pg_user" does not exist
>
>after some googling, i'm beginning to suspect that this is a SELinux
>issue. i then try to disable SELinux on the postgresql daemon by
>doing:
>
># setsebool postgresql_disable_trans true
>
>that does not work unfortunately as i'm still stuck with the same error.
>
>while i can definitely just disable SELinux on this box, i would want
>a more elegant solution that solves this annoying problem. can anyone
>help me on this?
>
>thanks in advance!
>matt
>
>  
>

Hi Matt,

On Tue, May 24, 2005 at 02:53:21PM +0800, Matt Arnilo S. Baluyos (Mailing Lists)
wrote:
> i'm trying to run a postgresql service on my newly-installed centos4
> box. i have been able to recreate my users, set up the permissions,
> and restore the database dump. also, i can already log-in to my
> databases.
> 
> there is, however, one annoying problem. whenever i type \du (or \d or
> \l) on the psql prompt, i get the following error:
> 
> ERROR:  relation "pg_catalog.pg_user" does not exist
Yep, I came across this a couple of months ago - it's an selinux bug on
postgres initialisation:

  https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=150979

There's an updated policy in that thread that fixes the problem, and
it'll be included in the upcoming RHEL4 U1.

Cheers,
Gavin

From: Peter Farrow <peter at farrows.org>
> As you have pointed out it restricts the security granularity of the 
> system, which in turn will lead to other "work arounds" to
achieve
> better granlarity and those work arounds will ultimately lead to 
> sloppiness, making Johns point very valid indeed.
First off, SELinux is _optional_ on a system-wide basis.

Secondly, SELinux does not have to affect various services, different distros
are free to ship different defaults.

Third, in typical Red Hat fashion, they adopt "new technologies with good
practices/standards" all-the-time.  We have to thank for forcing us back to
the GNU C Libraries and an ANSI C++ compiler which has drastically improved
run-time/binary compatibility.

Lastly, Red Hat, like many others, actually stick to standards.  I very much
dislike when people complain about "compatibility issues" when all
someone is trying to do is "get back to the standard" or "be
compliant with the new, universal standard."

E.g., several GNU projects -- from GCC 2.x's non-ANSI C++ implementation
(and especially the entire, multi-yser GCC 2.9.x "beta" merge of GCC
2.x and EGCS) to GNU Tar through 1.13 -- were forks from standards.  And when
people finally forced the issue of standards compliance, they get chastized.

Heck, one of the people I will always appreciate is Jorg, who has gotten reamed
left and right on cdrtools, star, etc...  He's probably one of the best
Linux developers leading full POSIX 2001 compliance (adding all the new IEEE/SUS
"Austin Group" developments in various programs).

Now SELinux isn't a half-bad design by the NSA and others.  Linux sorely
needed MAC and, to a lesser extent, Role Based Access Controls (RBAC) as
it's "legacy-only" UNIX access controls was not only falling
behind NT, but even most proprietary UNIX flavors.

But, again, it's _optional_.  Turn if off if you wish, but I think it's
about time a distro offered it, and attempted some secure defaults.  It is not
"sloppy" or "broken," just immature in application of
defaults yet -- especially since both developers and sysadmins are not used to
it being enabled.  So how SELinux any different than any other shift-adoption in
Red Hat's history?

Now my background is largely in defense with several years in financial (which
is, ironically, a major overlap in systems/network accounting, as well as
crypto, etc...).  And a lot of my job has been to go around and ensure
developers and integrators are adhering to security standards.  And I'm not
just one of those "complainy" types either -- because I'm also a
software engineer who regularly refutes the "I have to have root" or
"we have to do this" non-sense right back in their own language.

Especially when such cases are not really a security issue, but an engineering
workflow issue in the first place.  E.g., an software engineering development
system -- even with run-time and/or target on the same system -- should _never_
be designed so the development, run-time and/or target have full control of the
system.  All should be sandboxed in different ways so it's very easy for the
developer to tear down and rebuild the run-time/target from the development
tools.  If not, then the development environment is incomplete.

I don't know how many times I've seen engineers (and I'm one of them
too, so I know how they think) waste time fighting a system mis-configuration
they introduced because their development, run-time and/or target environments
are not finite and contained.  They believe they need full root on the system
when they don't.  And damn do I hate it when the network admins get on my
case because someone put a NIC in permisciuous mode -- the engineer
shouldn't even be able to do that!

With that said, the person who said that he's worked on Classified Networks
and said MAC is not a requirement needs to be re-briefed.  Access controls are
_always_ implemented, and if a system is unable to conform to the required
standard, there is a variance or other exception, and the risk must be mitigated
_and_ an "effective enough" manual procedure implemented.

I _explicitly_ used the term "accountable" because there are two types
of Classified Information -- "non-accountable" (typically US DoD
"Confidential" and most "Secret") and then their are
"accountable" (various, higher classifications).  You can typically
get away with common variances and other exceptions with minimal, additional
manual accounting for "non-accountable."  But any automation helps. 
When it comes to "accountable," MAC/RBAC really helps a crapload --
and the NSA really "got the ball rolling" for Linux, which was really
necessary.

As far as financial networks, don't even get me started.  ;->


--
Bryan J. Smith   mailto:b.j.smith at ieee.org

From: Feizhou <feizhou at graffiti.net>
> What is really needed is the ability to limit access to a file on a per 
> user account basis (acls), not by locking down via a group permission. 
And that's POSIX's ACLs, c/o the "Austin Group" work of the
IEEE POSIX
committee circa 2001 and the X/Open Single UNIX Specification (SUS)
version 3.

XFS on Linux has had POSIX ACL support since day one (using its own
codebase), and it's largely XFS's GPL contributions (and direct port
from Irix,
unlike IBM who ported JFS from OS/2 and not AIX) to kernel 2.6 (POSIX
ACL's were standardized as of the 2.5.3 development branch, thanx largely
to SGI).  Ext3 has had a varied history in the 2.4.x timeframe, and even
Red Hat gave up on them in Red Hat Linux 8.0 until kernel 2.6 in FC2+.

But even POSIX ACLs are _still_ Discretionary Access Controls (DAC),
atop of the legacy UNIX DACs we're all used to.  They just augment
discretionary control, and don't solve the MAC problem.

MAC limits you, not augments you with delegation, on purpose..  People
tend to hate MAC when they are first presented with the conepts, because
they expect them to work like DAC.  ;->


--
Bryan J. Smith   mailto:b.j.smith at ieee.org

From: Ted Kaczmarek <tedkaz at optonline.net>
> Thanks for the excellent post, no defense experience but dealing with
> the street side for quite a while now. 
I've worked at banks where the developers put the same routines for
"ATM withdrawl" in the same scope and access as the "back-end
debits/credits."
Their same attitude is, "oh, the system is secured by others."

And when you don't give up, they are arguing, "oh, it'll push back
the release date."
Some go as far as talking to management to get an override.

And then they _really_hate_you_ when you modify their code and show how easy it
is to actually make sure software, or implement MACs at the system-level that do
the same thing (but is incompatible with the software).
In a nutshell, there are a lot of coders out there that believe their software
and routines should access the entire system, no restrictions.

Although UNIX is typically better than Windows, largely because Microsoft's
application division still writes code for "Chicago" (including MS IE
to date), there are still cases where I can't trust it.
And I definitely need to make sure a compromise of one component is well outside
the access and scope of a more critical item it uses.


--
Bryan J. Smith   mailto:b.j.smith at ieee.org

From: Peter Farrow <peter at farrows.org>
> I still disable it though 'cause its a real pain....
Yes, because it's new, the defaults are immature, and the majority of both
developers and system administrators don't know much about it.  So disable
it and let others deal with it if the want to.  You have that choice.  ;->

But by making it the standard in its EL4 line (including FC2+, with changes in
FC3+ which RHEL4 inherited), it forces everyone to start learning it, start
reporting good defaults, and get it adopted as a standard by everyone.  Red Hat
does this all-the-time, and doesn't blink when people start screaming about
compatibility because it really only does it when it's really, really a
necessary adoption.  ;->

As I said before, one person I really feel for is Jorg.  The guy is
"on-the-ball" with POSIX developments, and reguarly gets chastized for
breaking compatibility to do so -- especially when some implementations (e.g.,
GNU Tar) were non-standard in the first place!  ;->



--
Bryan J. Smith   mailto:b.j.smith at ieee.org

Matt Arnilo S. Baluyos (Mailing Lists) wrote:
> while i can definitely just disable SELinux on this box, i would want
> a more elegant solution that solves this annoying problem. can anyone
> help me on this?
There's several bug report's on Red Hat's Bugzilla about PostgreSQL
and
SELinux.  You might want to check them out.  For starters, there's 
annoying bug that you must turn off SELinux (or set it to permissive 
mode) when you start PostgreSQL service for the very first time so that 
everything initializes correctly.  After that you can put it into 
enforcing mode again, and it will work OK.  If you haven't done that, 
you might want to reinitialize your PostgreSQL installation from scratch 
(remove everyting from /var/lib/pgsql/data directory).

Also, if your /tmp is on tmpfs, there are couple more issues to address 
(if /tmp is simply part of root file system like most people have it, 
you shouldn't have problems with it).

-- 
Aleksandar Milivojevic <amilivojevic at pbl.ca>    Pollard Banknote
Limited
Systems Administrator                           1499 Buffalo Place
Tel: (204) 474-2323 ext 276                     Winnipeg, MB  R3T 1L7