Re: unprivileged user - Mailing list pgsql-hackers

From Andrew Dunstan
Subject Re: unprivileged user
Date
Msg-id 4B218FA6.9030804@dunslane.net
Whole thread Raw
In response to Re: unprivileged user  (Peter Eisentraut <peter_e@gmx.net>)
List pgsql-hackers

Peter Eisentraut wrote:
> On tor, 2009-12-10 at 17:20 -0500, Andrew Dunstan wrote:
>   
>> Some time later it came up again, this time when someone wanted to use a 
>> readonly database (hence no pg_dump required) with an application and 
>> wanted to keep the database layout and the source code of stored 
>> functions hidden as they regarded it as proprietary information.
>>     
>
> Well, the information schema already implements a policy of this sort,
> because it only shows information about things you have some kind of
> access to. (I assume you are allowed to know about the things you have
> access to.)
>
> The problem in this sort of scheme is always that the system catalogs
> are world readable, and changing that would break about every tool and
> driver in existence.  It's not clear how to fix that, at least not
> without row-level security.  Or how did your old patch address this?
>
>
>   

Well, it will certainly break plenty of things. But it didn't prevent 
the client from doing the things we wanted to allow it to do, i.e. make 
a few function calls.

Basically what I did was to revoke public privileges from just about 
everything I could lay my hands on and regrant the same privileges to a 
group called pseudopublic, which contained every user but the one I 
wanted to restrict. The client I tested with was psql, and I recall 
being surprised that I was still able to do what I wanted - I had 
thought I would break things completely. I haven't tried to repeat the 
experiment recently, though.

cheers

andrew


pgsql-hackers by date:

Previous
From: Heiner Vega Thames
Date:
Subject: Viewing table data only from its corresponding oid-named file
Next
From: Bruce Momjian
Date:
Subject: Re: [GENERAL] Installing PL/pgSQL by default