>Marc G. Fournier wrote
> Does anyone know how ppl like Oracle handle this? Are system catalogs
> like this open to all users?
The system catalogs for Oracle and most other systems I know of are
secure.
In both Oracle and Teradata the "system tables" are actually views,
which are actively gran
On Mon, 29 Mar 2004, Andrew Dunstan wrote:
> It's that "probably" that niggles a bit. I don't know what usage
> patterns other people have, and since my typical use is exactly *one*
> user other than the owner/dba, and all access is mediated by my
> middleware, none of this affects me. ISTM we nee
On Mon, 29 Mar 2004, Marc G. Fournier wrote:
> On Mon, 29 Mar 2004, Dave Page wrote:
>
> > It's rumoured that Euler Taveira de Oliveira once said:
> > > Hi Christopher,
> > >
> > >> > "The \l command should only list databases that the current user is
> > >> > authorized for, the \du command shou
Tom Lane wrote:
Andrew Dunstan <[EMAIL PROTECTED]> writes:
I just played around briefly with removing *all* public access to a
couple of catalog tables - pg_class and pg_attrdef. Obviously this
breaks things like \d and friends. I'm not sure how much else it might
break -
pg_dump, for
It's rumoured that Marc G. Fournier once said:
> On Mon, 29 Mar 2004, Dave Page wrote:
>
> k, but what I'm suggesting shouldn't prevent that, should it? They
> should only be able to see those resources that they have permissions
> to see, not all of them ... no?
Wouldn't that require per-row per
On Mon, 29 Mar 2004, Dave Page wrote:
> It's rumoured that Euler Taveira de Oliveira once said:
> > Hi Christopher,
> >
> >> > "The \l command should only list databases that the current user is
> >> > authorized for, the \du command should only list users authorized
> >> > for the current databas
Andrew Dunstan <[EMAIL PROTECTED]> writes:
> I just played around briefly with removing *all* public access to a
> couple of catalog tables - pg_class and pg_attrdef. Obviously this
> breaks things like \d and friends. I'm not sure how much else it might
> break -
pg_dump, for starters ...
I'
It's rumoured that Euler Taveira de Oliveira once said:
> Hi Christopher,
>
>> > "The \l command should only list databases that the current user is
>> > authorized for, the \du command should only list users authorized
>> > for the current database (and perhaps only superusers should get
>> > even
On Mon, 29 Mar 2004, Andrew Dunstan wrote:
> My previous answer to this question has been "use a middleware layer
> that exposes just the operations you want exposed". But this issue has
> come up a few times so maybe some more thought is needed. Of course, we
> are only talking about metadata her
Hi Christopher,
> > "The \l command should only list databases that the current user is
> > authorized for, the \du command should only list users authorized for the
> > current database (and perhaps only superusers should get even that much
> > information), etc. Perhaps it is possible to set PG
Christopher Kings-Lynne wrote:
"The \l command should only list databases that the current user is
authorized for, the \du command should only list users authorized for
the
current database (and perhaps only superusers should get even that much
information), etc. Perhaps it is possible to set PG
"The \l command should only list databases that the current user is
authorized for, the \du command should only list users authorized for the
current database (and perhaps only superusers should get even that much
information), etc. Perhaps it is possible to set PG to do this, but that
should prob
How hard would it be to add this:
"The \l command should only list databases that the current user is
authorized for, the \du command should only list users authorized for the
current database (and perhaps only superusers should get even that much
information), etc. Perhaps it is possible to set
13 matches
Mail list logo
