[CentOS] PostgreSQL/SELinux Error - relation "pg_catalog.pg_user" does not exist

John Logsdon j.logsdon at quantex-research.com
Tue May 24 09:49:08 UTC 2005


I would agree with Peter on SEL and I have it disabled even though of
course the userland tools are still SEL-modified and we have to use
libselinux everywhere.

{rant}

One thing that is incredibly annoying with the packaging of *all* Linuxes
that I have seen is the sloppy access controls even in the so-called
paranoid settings, which only apply to the firewall aspects really.  
Maybe there are exceptions but even the installation scripts leave files
644 or similar when they only need to be 600.  If a file is in user and
group for root, then apart from the few other system users that are also
members of the root group, 600 is perfectly adequate or 611 if it's a
directory and 'go' want to access files within the directory.  I wish the
package providers would realise this.

At the user level, RH (? was it them?) started off the fashion of giving
every user their own group.  So groups become immediately pointless.  
Debian put all users in the same group users - almost as silly.  Groups
enable a very powerful control mechanism and ignoring them removes at
least one dimension from the security.

I know next to nothing about NT controls so I can't comment on whether
Linux 'meets' some arbitrary requirements but by (a) limiting access to
system files to root (ie the user) and those few other users and (b)
fluent use of groups it is possible to use the DAC to close down almost
everything.

And to finish the job, use grsecurity which is fairly easy to configure -
it appears to be much easier than SEL in particular - and doesn't need any
userland tools as it is entirely in the kernel.

{\rant}

Sorry about that!

John
 
John Logsdon                               "Try to make things as simple
Quantex Research Ltd, Manchester UK         as possible but not simpler"
j.logsdon at quantex-research.com              a.einstein at relativity.org
+44(0)161 445 4951/G:+44(0)7717758675       www.quantex-research.com


On Tue, 24 May 2005, Peter Farrow wrote:

> Maybe so... and if it works for you then use it, but sometimes when 
> people say  "but we needed this or we needed that",  they haven't 
> allways sat down and thought "why do we need it" or "do we really 'need' 
> this ?"
> 
> Even having worked on government classified networks I have *never* seen 
> an instance where the standard access controls offered by Linux/Unix 
> didn't do what was required.
> 
> Often DAC/MAC setups leads to inferior security because they can get 
> very complex to setup, and the term "can't see the wood for the trees" 
> springs to mind.
> 
> As is most often the case the best security is the simplest, and DAC/MAC 
> bloat doesn't help in any way.
> 
> If some document or requirement or spec says you need it, I would often 
> question the theory behind the spec, and only if a demonstrable need 
> arises (have yet to see that in 20+ years of consulting) then I would do 
> it...
> 
> Of course I've also been in this game too long as well to "never say 
> never" and there is always a first time....  :-)
> 
> P.
> 
> 
> 
> 
> Bryan J. Smith wrote:
> 
> >On Tue, 2005-05-24 at 08:24 +0100, Peter Farrow wrote:
> >  
> >
> >>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...
> >>    
> >>
> >
> >Unfortunately, Mandatory Access Controls (MACs) are a necessary
> >accountability detail needed in many environments.
> >
> >It's really the only place NT was better than legacy UNIX.
> >
> >Of course, I would return argue that Linux at least addresses all
> >aspects of the 7 domains of the SSCP _except_ the MAC portion of
> >DAC/MAC, whereas Microsoft only addresses 3 of them in the OS as
> >standard.
> >
> >But we needed MAC.  It's a good thing to have in many environments --
> >especially where accountability is essential.
> >
> >
> >  
> >
> 




More information about the CentOS mailing list