On Fri, Jul 28, 2006 at 04:42:11PM -0400, Phil Frost wrote:
> Again, fix is really simple. Document the issue, making it damn clear in
> the docs that the schema usage check means *nothing* when accessing an
> object by OID, and advising users that the ways to access things by OID
> are obscure but
Phil Frost wrote:
> Again, fix is really simple. Document the issue, making it damn clear in
> the docs that the schema usage check means *nothing* when accessing an
> object by OID, and advising users that the ways to access things by OID
> are obscure but present and changing, so relying on the
On Fri, Jul 28, 2006 at 09:54:38PM +0200, Martijn van Oosterhout wrote:
> Not the least of which is that arguments involving "people can install
> C code into the backend and break security" are truisms: installed C
> code can do *anything* which is why only superusers can install such
> functions.
On Thu, Jul 27, 2006 at 09:37:22PM -0400, Stephen Frost wrote:
> Got any others beyond 'lastval'? Is 'lastval' even doing what you're
> claiming (looking at the actual catalog on disk by using the OID)? My
> recollection was that it was actually just storing the value in a bit of
> backend-local
* Phil Frost ([EMAIL PROTECTED]) wrote:
> Granted, I can't think of too many ways one could store sensitive
> information in a sequence. I think it's more important to consider what
> it implies about the system behind the issue. When I revoke some
> privilege, I expect it to be enforced regardless
On Thu, Jul 27, 2006 at 05:01:37PM -0400, Andrew Dunstan wrote:
> Tom Lane wrote:
>
> >Alvaro Herrera <[EMAIL PROTECTED]> writes:
> >>What we should really do is have lastval() fail if the user does not
> >>have appropiate permissions on the schema. Having it not fail is a bug,
> >>and documentin
On Thu, Jul 27, 2006 at 04:40:45PM -0400, Tom Lane wrote:
> Alvaro Herrera <[EMAIL PROTECTED]> writes:
> > What we should really do is have lastval() fail if the user does not
> > have appropiate permissions on the schema. Having it not fail is a bug,
> > and documenting a bug turns it not into a
Tom Lane wrote:
Alvaro Herrera <[EMAIL PROTECTED]> writes:
What we should really do is have lastval() fail if the user does not
have appropiate permissions on the schema. Having it not fail is a bug,
and documenting a bug turns it not into a feature, but into a "gotcha".
I'm unconvin
Alvaro Herrera <[EMAIL PROTECTED]> writes:
> What we should really do is have lastval() fail if the user does not
> have appropiate permissions on the schema. Having it not fail is a bug,
> and documenting a bug turns it not into a feature, but into a "gotcha".
I'm unconvinced that it's either a
Phil Frost wrote:
> On Thu, Jul 27, 2006 at 06:36:30PM +0200, Peter Eisentraut wrote:
> > I'm sure some people agree that there is a problem. It would help,
> > however, if you were not talking about two different things at once.
> > And it would help if you actually proposed a change that would
Phil Frost wrote:
> What two things are there?
Well, the subject says "lastval exposes information that currval does
not" while you are talking about schema permissions. I still don't
know what you're really after. One of your posts stated that you have
repeatedly demonstrated ways to overcom
On Thu, Jul 27, 2006 at 06:36:30PM +0200, Peter Eisentraut wrote:
> I'm sure some people agree that there is a problem. It would help,
> however, if you were not talking about two different things at once.
> And it would help if you actually proposed a change that would improve
> matters.
What
Phil Frost wrote:
> All right, I give up. I guess no one seems to want to admit this is a
> bad security policy, or accurately document it. Does that make it an
> easter egg?
I'm sure some people agree that there is a problem. It would help,
however, if you were not talking about two different t
All right, I give up. I guess no one seems to want to admit this is a
bad security policy, or accurately document it. Does that make it an
easter egg?
On Thu, Jul 20, 2006 at 01:59:43PM -0400, Bruce Momjian wrote:
>
> OK, text again updated:
>
>For schemas, allows access to objects conta
OK, text again updated:
For schemas, allows access to objects contained in the specified
schema (assuming that the objects' own privilege requirements are
also met). Essentially this allows the grantee to look up
objects within the schema. Without this permission, it
On Wed, Jul 19, 2006 at 02:42:49PM -0400, Bruce Momjian wrote:
> Updated text:
>
>For schemas, allows access to objects contained in the specified
>schema (assuming that the objects' own privilege requirements are
>also met). Essentially this allows the grantee to look up
Phil Frost wrote:
> On Wed, Jul 12, 2006 at 06:09:31PM -0400, Bruce Momjian wrote:
> > Phil Frost wrote:
> > > On Wed, Jul 12, 2006 at 11:37:37AM -0400, Bruce Momjian wrote:
> > > >
> > > > Updated text:
> > > >
> > > >For schemas, allows access to objects contained in the specified
> > >
On Wed, Jul 12, 2006 at 06:09:31PM -0400, Bruce Momjian wrote:
> Phil Frost wrote:
> > On Wed, Jul 12, 2006 at 11:37:37AM -0400, Bruce Momjian wrote:
> > >
> > > Updated text:
> > >
> > >For schemas, allows access to objects contained in the specified
> > >schema (assuming that th
Phil Frost wrote:
> On Wed, Jul 12, 2006 at 11:37:37AM -0400, Bruce Momjian wrote:
> >
> > Updated text:
> >
> >For schemas, allows access to objects contained in the specified
> >schema (assuming that the objects' own privilege requirements are
> >also met). Essentially
On Wed, Jul 12, 2006 at 11:37:37AM -0400, Bruce Momjian wrote:
>
> Updated text:
>
>For schemas, allows access to objects contained in the specified
>schema (assuming that the objects' own privilege requirements are
>also met). Essentially this allows the grantee to look
Updated text:
For schemas, allows access to objects contained in the specified
schema (assuming that the objects' own privilege requirements are
also met). Essentially this allows the grantee to look up
objects within the schema. Without this permission, it is still
On 7/9/2006 8:32 AM, Martijn van Oosterhout wrote:
On Sat, Jul 08, 2006 at 05:47:33PM -0400, Jim Nasby wrote:
On Jul 6, 2006, at 11:02 AM, Phil Frost wrote:
>I hope the above example is strong enough to elicit a comment from a
>qualified developer. If it is not, consider that stored procedures
* Phil Frost ([EMAIL PROTECTED]) wrote:
> I haven't found a way to do this yet, but I wouldn't be suprised if
> there is a clever way, especially considering C extensions that might
> come from contrib or other sources. It seems like there is a good deal
> of potential for non-malicious developers
On Mon, Jul 10, 2006 at 08:24:08PM +0200, Martijn van Oosterhout wrote:
> On Mon, Jul 10, 2006 at 01:42:27PM -0400, Phil Frost wrote:
> > I think that misses the point. One can easily find objects in a schema
> > without usage by examining the system catalogs. The point is that there
> > are ways t
On Mon, Jul 10, 2006 at 01:42:27PM -0400, Phil Frost wrote:
> I think that misses the point. One can easily find objects in a schema
> without usage by examining the system catalogs. The point is that there
> are ways to access objects without going through the schema usage check,
> and also that t
On Mon, Jul 10, 2006 at 12:49:54PM -0400, Bruce Momjian wrote:
>
> Docs updated:
>
>
>For schemas, allows the grantee to find objects contained in the
>specified schema (assuming that the objects' own privilege requirements
>are also met).
>
I think that mis
Docs updated:
For schemas, allows the grantee to find objects contained in the
specified schema (assuming that the objects' own privilege requirements
are also met).
---
Martijn van Ooste
On Sun, Jul 09, 2006 at 11:24:38AM -0400, Phil Frost wrote:
> On UNIX it is also clearly defined that if one does not have execute
> permissions on a directory, one can not open files within it by *any*
> *means*. There are no procedures that bypass this by taking an inode
> number directly.
Well,
On Sun, Jul 09, 2006 at 02:32:24PM +0200, Martijn van Oosterhout wrote:
> On Sat, Jul 08, 2006 at 05:47:33PM -0400, Jim Nasby wrote:
> > On Jul 6, 2006, at 11:02 AM, Phil Frost wrote:
> > >I hope the above example is strong enough to elicit a comment from a
> > >qualified developer. If it is not, c
On Sat, Jul 08, 2006 at 05:47:33PM -0400, Jim Nasby wrote:
> On Jul 6, 2006, at 11:02 AM, Phil Frost wrote:
> >I hope the above example is strong enough to elicit a comment from a
> >qualified developer. If it is not, consider that stored procedures
> >contain prepared statements, and many client a
On Jul 6, 2006, at 11:02 AM, Phil Frost wrote:
I hope the above example is strong enough to elicit a comment from a
qualified developer. If it is not, consider that stored procedures
contain prepared statements, and many client applications cache
prepared
statements as well. Thus, revoking usag
On Wed, Jul 05, 2006 at 05:57:08PM -0700, Joshua D. Drake wrote:
>
> > I am well aware of what security definer means. The significant part of
> > this example is that lastval() will allow the caller to see the value of
> > a sequence where currval('seq') will not. This means that things which
> >
> I am well aware of what security definer means. The significant part of
> this example is that lastval() will allow the caller to see the value of
> a sequence where currval('seq') will not. This means that things which
> might have been forbidden in 8.0 are now accessible in 8.1.
>
> It also me
On Wed, Jul 05, 2006 at 08:06:12PM -0400, Chris Campbell wrote:
> On Jul 5, 2006, at 14:51, Phil Frost wrote:
>
> >test=# create function bump() returns bigint language sql security
> >definer as $$ select nextval('private.seq'); $$;
>
> SECURITY DEFINER means that the function runs with the pe
On Jul 5, 2006, at 14:51, Phil Frost wrote:
test=# create function bump() returns bigint language sql security
definer as $$ select nextval('private.seq'); $$;
SECURITY DEFINER means that the function runs with the permissions of
the role used to create the function (ran the CREATE FUNCTION
test=# create schema private;
CREATE SCHEMA
test=# create sequence private.seq;
CREATE SEQUENCE
test=# create function bump() returns bigint language sql security definer as
$$ select nextval('private.seq'); $$;
CREATE FUNCTION
test=# revoke usage on schema private from pfrost;
REVOKE
test=# grant
36 matches
Mail list logo
