On Sat, May 14, 2005 at 10:00:09AM -0400, Stephen Frost wrote:
> * Jim C. Nasby ([EMAIL PROTECTED]) wrote:
> > On Sat, May 14, 2005 at 08:55:17AM -0400, Stephen Frost wrote:
> > > * Christopher Kings-Lynne ([EMAIL PROTECTED]) wrote:
> > > > Hackers - we get an email about information hiding in shar
* Jim C. Nasby ([EMAIL PROTECTED]) wrote:
> On Sat, May 14, 2005 at 08:55:17AM -0400, Stephen Frost wrote:
> > * Christopher Kings-Lynne ([EMAIL PROTECTED]) wrote:
> > > Hackers - we get an email about information hiding in shared
> > > postgresql/phppgadmin installations at least once a fortnight
On Sat, May 14, 2005 at 08:55:17AM -0400, Stephen Frost wrote:
> * Christopher Kings-Lynne ([EMAIL PROTECTED]) wrote:
> > >It bothers me a great deal that I can't control very easily what a given
> > >user can see when they connect over ODBC or via phppgadmin in terms of
> > >schemas, tables and co
* Christopher Kings-Lynne ([EMAIL PROTECTED]) wrote:
> >It bothers me a great deal that I can't control very easily what a given
> >user can see when they connect over ODBC or via phppgadmin in terms of
> >schemas, tables and columns. I fixed this in application code in
> >phppgadmin but that's cl
Tom mentioned that he had not had these security concerns raised before. From
my point of view I just have no idea about the level of information offered
to any given user and am scared to run PostgreSQL in an ISP shared
environment because of it. I am sure I can secure people from connecting
* Russell Smith ([EMAIL PROTECTED]) wrote:
> Tom mentioned that he had not had these security concerns raised before.
> From
> my point of view I just have no idea about the level of information offered
> to any given user and am scared to run PostgreSQL in an ISP shared
> environment because
On Sat, May 14, 2005 at 12:25:01PM +1000, Russell Smith wrote:
> - Which parts of other databases can be seen by users?
The name, username of the owner, etc. No table names, for example.
The user list is also visible to everyone, across databases.
> - What is the best method to restrict connect
On Sat, 14 May 2005 04:34 am, Andrew Dunstan wrote:
>
> Andrew - Supernews wrote:
>
> >>
> >>1) The "ISP" case, where you want to hide all catalog information from the
> >>users except the database owner or superuser.
> >>
> >>
> >
> >I don't believe this is ever feasible in practice, since
Andrew - Supernews wrote:
1) The "ISP" case, where you want to hide all catalog information from the
users except the database owner or superuser.
I don't believe this is ever feasible in practice, since client interfaces
at any level higher than libpq will need to access metadata correspond
On 2005-05-13, Josh Berkus wrote:
> Andrew,
>> It might be safer, but that doesn't hit my target at all. I am aiming at
>> a zero-knowledge user, i.e. one who cannot discover anything at all
>> about the db. The idea is that even if subvert can subvert a client and
>> get access to the db the amou
Andrew,
> It might be safer, but that doesn't hit my target at all. I am aiming at
> a zero-knowledge user, i.e. one who cannot discover anything at all
> about the db. The idea is that even if subvert can subvert a client and
> get access to the db the amount of metadata they can discover is as
>
11 matches
Mail list logo