lastval exposes information that currval does not
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 select, update on private.seq to pfrost;
GRANT
test=# set role pfrost;
SET
test=> select bump();
bump
------
1
(1 row)
test=> select nextval('private.seq');
ERROR: permission denied for schema private
test=> select currval('private.seq');
ERROR: permission denied for schema private
test=> select lastval();
lastval
---------
1
(1 row)
Aparrently, lastval remembers the last sequence by OID, and the check
for usage on a schema is made when resolving a name to an OID. Thus, the
schema usage check is never made for lastval.
Firstly there is the problem that this potentially reveals information
that was not visible prior to 8.1. Granted, I don't think this is a
serious security issue for most applications, but it does suprise me.
There is also the larger problem of the implementation of schema usage
checks. More serious functions might be added in the future that suffer
from the same vulnerability. For all I know, there might be some now. I
should think that a much better place for this check would be in the
same place that checks the ACL for the object itself.
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
command). Due to your # prompt, I'm guessing that you were a
superuser when you ran this command. Thus, bump() will be run with
the superuser's permissions.
The superuser most definitely has permissions to access private.seq.
This has nothing to do with schema security or lastval() versus
currval().
Check out the CREATE FUNCTION documentation:
http://www.postgresql.org/docs/8.1/interactive/sql-
createfunction.html
- Chris
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 permissions of
the role used to create the function (ran the CREATE FUNCTION
command). Due to your # prompt, I'm guessing that you were a
superuser when you ran this command. Thus, bump() will be run with
the superuser's permissions.The superuser most definitely has permissions to access private.seq.
This has nothing to do with schema security or lastval() versus
currval().Check out the CREATE FUNCTION documentation:
http://www.postgresql.org/docs/8.1/interactive/sql-
createfunction.html
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 means that revoking usage on a schema is not sufficient to
prevent a user from accessing things within that schema, a property that
makes me quite uncomfortable.
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 means that revoking usage on a schema is not sufficient to
prevent a user from accessing things within that schema, a property that
makes me quite uncomfortable.
Then the public schema must drive you nuts :). If you were to create the
function as a non-super user you would probably be good.
Joshua D. Drake
---------------------------(end of broadcast)---------------------------
TIP 3: Have you checked our extensive FAQ?
--
=== The PostgreSQL Company: Command Prompt, Inc. ===
Sales/Support: +1.503.667.4564 || 24x7/Emergency: +1.800.492.2240
Providing the most comprehensive PostgreSQL solutions since 1997
http://www.commandprompt.com/
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
might have been forbidden in 8.0 are now accessible in 8.1.It also means that revoking usage on a schema is not sufficient to
prevent a user from accessing things within that schema, a property that
makes me quite uncomfortable.Then the public schema must drive you nuts :). If you were to create the
function as a non-super user you would probably be good.Joshua D. Drake
I use the public schema for public things. You are still missing the
point of the example. I could have written it any number of other ways.
I could have granted update, but not select on the sequence to the
non-superuser.
Not using security definer will not change the fact that although I can
not use currval to get the current value of the sequence, I can get it
with lastval. This behavour is unexpected, not explicitly documented,
not really useful, and new in 8.1. This means it could potentially open
new security holes in existing programs. The suprising and hardly
documented behaviour means that new programs are likely to be
vulnerable.
More importantly, it reveals that the security check for schema usage is
not part of the ACL check for actions like selecting a table. This means
that revoking usage on a schema provides no security guarantee. For
example:
test=# create schema private;
test=# grant usage on schema private to public;
test=# create table private.insecure as select 1;
test=# grant select on private.insecure to public;
test=# set role pfrost;
test=> prepare exploit as select * from private.insecure;
test=> reset role;
test=# revoke usage on schema private from public;
test=# set role pfrost;
test=> select * from private.insecure;
ERROR: permission denied for schema private
test=> execute exploit;
?column?
----------
1
(1 row)
test=>
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 usage on a schema is about as good as
nothing until all sessions have ended. It also means that any function
which operates with OIDs can potentially bypass the schema usage check.
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 usage on a schema is about as
good as
nothing until all sessions have ended. It also means that any function
which operates with OIDs can potentially bypass the schema usage
check.
I'm pretty sure that's by design, especially given this tidbit of the
docs:
"Essentially this allows the grantee to "look up" objects within the
schema."
Though perhaps the intention is to change this once we have a means
to invalidate plans.
The docs probably should elaborate that once something's been looked
up you no longer need permissions on the schema it resides in.
--
Jim C. Nasby, Sr. Engineering Consultant jnasby@pervasive.com
Pervasive Software http://pervasive.com work: 512-231-6117
vcard: http://jim.nasby.net/pervasive.vcf cell: 512-569-9461
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 applications cache
prepared
statements as well. Thus, revoking usage on a schema is about as
good as
nothing until all sessions have ended. It also means that any function
which operates with OIDs can potentially bypass the schema usage
check.The docs probably should elaborate that once something's been looked
up you no longer need permissions on the schema it resides in.
I'm not sure this is really unexpected behaviour. On UNIX it is clearly
defined that file permissions are checked only on open. Once you've
opened it, changing permissions on the file won't affect you. If
someone passes you a read/write descriptor to a file, you can
read/write it even if you didn't have permissions to open the
file/socket/whatever yourself.
I'm not sure it makes sense to be able to revoke someone's permissions
on an object they've already accessed. From a transactional point of
view, the revoke should at the very least not affect transactions
started prior to the revokation. Some things are shared across an
entire session, and the rule extends to them. Is this a bug? Maybe, but
it is debatable.
Have a nice day,
--
Martijn van Oosterhout <kleptog@svana.org> http://svana.org/kleptog/
Show quoted text
From each according to his ability. To each according to his ability to litigate.
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, consider that stored procedures
contain prepared statements, and many client applications cache
prepared
statements as well. Thus, revoking usage on a schema is about as
good as
nothing until all sessions have ended. It also means that any function
which operates with OIDs can potentially bypass the schema usage
check.The docs probably should elaborate that once something's been looked
up you no longer need permissions on the schema it resides in.I'm not sure this is really unexpected behaviour. On UNIX it is clearly
defined that file permissions are checked only on open. Once you've
opened it, changing permissions on the file won't affect you. If
someone passes you a read/write descriptor to a file, you can
read/write it even if you didn't have permissions to open the
file/socket/whatever yourself.I'm not sure it makes sense to be able to revoke someone's permissions
on an object they've already accessed. From a transactional point of
view, the revoke should at the very least not affect transactions
started prior to the revokation. Some things are shared across an
entire session, and the rule extends to them. Is this a bug? Maybe, but
it is debatable.
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.
It is generally understood in the UNIX commuinity that adding a function
in a new version that grants capabilities that were previously
unavailable is an obvious security bug.
If it doesn't make sense to be able to revoke permissions on objects
already accessed, why is this the behaviour of everything except the
schema usage check? Does your definition of "already accessed" include
"accessed in a 'security definer' procedure intended to prevent the
caller from accessing an object directly"?
Given that there are already several ways to bypass the check for usage
on a schema, and the developers seem to not be bothered at all by adding
more, of what security use is the schema usage privilege?
Is drawing a weak analogy to another system with a significantly
different security model a good way to validate security for PostgreSQL?
Is it a good idea to have a privilege with surprising semantics?
I'm sorry to keep arguing about this issue, but I am quite disturbed
with the lack of concern over security in the developer commuinity.
Perhaps the mindset here is that the SQL server will always be behind a
firewall and accessed through a web application. I'm here to say this is
not the case. Firewalls are comprimised, and not all applications are
web applications. I'd really not like to have to write a middleware
server just because the security in PostgreSQL is insufficient.
At a minimum, I'd like to see the documentation updated to document the
weakness of the usage privilege, and how to prevent these exploits. I'll
write the patch if there is agreement. Ideally, I'd like to see the
usage privilege changed to something more consistent and useful.
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, not entirely true. If a file exists in multiple directories, you
can open it as long as any of the directories are currently accessable
to you (which is not the same as being accessable if you logged in
again).
However, the issue has been confused here by two completely different
examples. In one case you prepare a statement and then execute it later
which succeeds even though if you reprepared the statement it would
fail. This is no different from the UNIX case where having an open file
survives removing of permissions and even deletion.
It is generally understood in the UNIX commuinity that adding a function
in a new version that grants capabilities that were previously
unavailable is an obvious security bug.
In this case you're referring to the lastval() issue. That case is
debatable I guess... You're suggesting it return a permission error
instead.
It's a little odd, though it think it's defensible position though. IMO
you should simply drop the lastval() function altogether, since I don't
think it's really that useful in exchange for the problems it creates.
If it doesn't make sense to be able to revoke permissions on objects
already accessed, why is this the behaviour of everything except the
schema usage check? Does your definition of "already accessed" include
"accessed in a 'security definer' procedure intended to prevent the
caller from accessing an object directly"?
Well, that's a good question. At a guess it's because the
select/update/delete permissions are a property of the table, whereas
the schema is not. The table is a member of the schema. All that
suggests is that you should be revoking the permissions on the table
itself, rather than on the schema.
In the same vein, when reloading the pg_hba.conf, the database doesn't
immediatly disconnect all users who would be disallowed by the new
rules.
Given that there are already several ways to bypass the check for usage
on a schema, and the developers seem to not be bothered at all by adding
more, of what security use is the schema usage privilege?
Several other ways? If there were a case where a user who has never had
access to a schema could access something in it, that would be an
issue. But arguing about when a revoke should take effect is a
completely different issue.
IME the developers are extremely interested in security issues.
At a minimum, I'd like to see the documentation updated to document the
weakness of the usage privilege, and how to prevent these exploits. I'll
write the patch if there is agreement. Ideally, I'd like to see the
usage privilege changed to something more consistent and useful.
I think it might be helpful for the documentation to state that USAGE
controls whether people can lookup objects within a schema and that
removing USAGE doesn't block access to the objects themselves, only
that they may not be referred to by name. To do that you need to revoke
permissions on the objects themselves.
I'm not a core developer though, so my opinions aren't really that
relevent. Do other database systems work the way you expect?
Have a nice day,
--
Martijn van Oosterhout <kleptog@svana.org> http://svana.org/kleptog/
Show quoted text
From each according to his ability. To each according to his ability to litigate.
Docs updated:
<para>
For schemas, allows the grantee to find objects contained in the
specified schema (assuming that the objects' own privilege requirements
are also met).
</para>
---------------------------------------------------------------------------
Martijn van Oosterhout wrote:
-- Start of PGP signed section.
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, not entirely true. If a file exists in multiple directories, you
can open it as long as any of the directories are currently accessable
to you (which is not the same as being accessable if you logged in
again).However, the issue has been confused here by two completely different
examples. In one case you prepare a statement and then execute it later
which succeeds even though if you reprepared the statement it would
fail. This is no different from the UNIX case where having an open file
survives removing of permissions and even deletion.It is generally understood in the UNIX commuinity that adding a function
in a new version that grants capabilities that were previously
unavailable is an obvious security bug.In this case you're referring to the lastval() issue. That case is
debatable I guess... You're suggesting it return a permission error
instead.It's a little odd, though it think it's defensible position though. IMO
you should simply drop the lastval() function altogether, since I don't
think it's really that useful in exchange for the problems it creates.If it doesn't make sense to be able to revoke permissions on objects
already accessed, why is this the behaviour of everything except the
schema usage check? Does your definition of "already accessed" include
"accessed in a 'security definer' procedure intended to prevent the
caller from accessing an object directly"?Well, that's a good question. At a guess it's because the
select/update/delete permissions are a property of the table, whereas
the schema is not. The table is a member of the schema. All that
suggests is that you should be revoking the permissions on the table
itself, rather than on the schema.In the same vein, when reloading the pg_hba.conf, the database doesn't
immediatly disconnect all users who would be disallowed by the new
rules.Given that there are already several ways to bypass the check for usage
on a schema, and the developers seem to not be bothered at all by adding
more, of what security use is the schema usage privilege?Several other ways? If there were a case where a user who has never had
access to a schema could access something in it, that would be an
issue. But arguing about when a revoke should take effect is a
completely different issue.IME the developers are extremely interested in security issues.
At a minimum, I'd like to see the documentation updated to document the
weakness of the usage privilege, and how to prevent these exploits. I'll
write the patch if there is agreement. Ideally, I'd like to see the
usage privilege changed to something more consistent and useful.I think it might be helpful for the documentation to state that USAGE
controls whether people can lookup objects within a schema and that
removing USAGE doesn't block access to the objects themselves, only
that they may not be referred to by name. To do that you need to revoke
permissions on the objects themselves.I'm not a core developer though, so my opinions aren't really that
relevent. Do other database systems work the way you expect?Have a nice day,
--
Martijn van Oosterhout <kleptog@svana.org> http://svana.org/kleptog/From each according to his ability. To each according to his ability to litigate.
-- End of PGP section, PGP failed!
--
Bruce Momjian bruce@momjian.us
EnterpriseDB http://www.enterprisedb.com
+ If your life is a hard drive, Christ can be your backup. +
On Mon, Jul 10, 2006 at 12:49:54PM -0400, Bruce Momjian wrote:
Docs updated:
<para>
For schemas, allows the grantee to find objects contained in the
specified schema (assuming that the objects' own privilege requirements
are also met).
</para>
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 the check is made only once at the time a name is resolved
to an oid, which may then be cached in a prepared statement, stored
procedure, lastval, or the like. I would suggest something more like
this:
For schemas, allows the grantee to reference objects within the
specified schema by name. Note that any method of accessing an
object that does not involve naming will not check for this
privilege. For example, any function taking an OID parameter or
lastval(). Also, the check for this privilege will be made only once
when a query is planned, so stored plans such as from prepared
statements or stored procedures will not make the check again when
subsequently executed.
In applications where security is very important, it may be wise to
assure that no users have undesired privileges on objects within a
schema, and not to rely solely on the schema usage privilege.
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 the check is made only once at the time a name is resolved
to an oid, which may then be cached in a prepared statement, stored
procedure, lastval, or the like. I would suggest something more like
this:
Can you SELECT/UPDATE/DELETE from a table knowing only its oid? I'd
like to see that trick. lastval() is an odd case, given the user
doesn't actually supply the oid.
In applications where security is very important, it may be wise to
assure that no users have undesired privileges on objects within a
schema, and not to rely solely on the schema usage privilege.
Indeed, never give priveledges unless you're sure you want people to
have them.
Have a nice day,
--
Martijn van Oosterhout <kleptog@svana.org> http://svana.org/kleptog/
Show quoted text
From each according to his ability. To each according to his ability to litigate.
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 to access objects without going through the schema usage check,
and also that the check is made only once at the time a name is resolved
to an oid, which may then be cached in a prepared statement, stored
procedure, lastval, or the like. I would suggest something more like
this:Can you SELECT/UPDATE/DELETE from a table knowing only its oid? I'd
like to see that trick. lastval() is an odd case, given the user
doesn't actually supply the oid.
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 to open unknowingly serious
security holes. I think lastval is a great example of this potential;
fortunately sequence values are rarely compromising. Imagine the
consequences of a function which returns the last inserted row in a
similar manner.
In applications where security is very important, it may be wise to
assure that no users have undesired privileges on objects within a
schema, and not to rely solely on the schema usage privilege.Indeed, never give priveledges unless you're sure you want people to
have them.
The way I ran into this problem is moving a table that was previously in
a public schema into a private schema. Since not having usage on the
schema is enough to prevent access most of the time, the change passed
testing. Later I noticed the odd grant on some objects in the private
schema, and poking around I found ways to access them dispite not having
usage on the schema.
The "check just once at plan time, and only when referencing an object
by name" semantics of the schema usage check which differ from the
"check always" semantics of all the other ACL checks I found to be
suprising. Since these fine details are not obvious, expected, or
documented, there seems to be a good deal of potential for
administrative error. Hopefully at least the docs will be updated so
people can at least be aware of the issue.
* Phil Frost (indigo@bitglue.com) 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 to open unknowingly serious
security holes. I think lastval is a great example of this potential;
fortunately sequence values are rarely compromising. Imagine the
consequences of a function which returns the last inserted row in a
similar manner.
Yes, you can compromise the security of the system by loading C modules.
That's not going to change. If you find examples of such compromises in
core, or in contrib, please bring them to our attention. As for from
other sources, well, you'd have to bring it up with that source..
Thanks,
Stephen
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
contain prepared statements, and many client applications cache
prepared
statements as well. Thus, revoking usage on a schema is about as
good as
nothing until all sessions have ended. It also means that any function
which operates with OIDs can potentially bypass the schema usage
check.The docs probably should elaborate that once something's been looked
up you no longer need permissions on the schema it resides in.I'm not sure this is really unexpected behaviour. On UNIX it is clearly
defined that file permissions are checked only on open. Once you've
opened it, changing permissions on the file won't affect you. If
someone passes you a read/write descriptor to a file, you can
read/write it even if you didn't have permissions to open the
file/socket/whatever yourself.
This isn't the case and I do agree with Phil on this. The fact that
another "security definer" function did access an object during the
session should not give the user the ability to access it in the manner
shown in his example. lastval() without arguments should not remember
the sequence by its oid only, but also remember the sequences schema and
to a proper ACL check on that as well.
Just think of it if SELECT without a FROM clause would automatically
assume the same rangetable as the last SELECT in the session. If that
were the case, would you guy's defend the position that "SELECT *" then
should spit out the full content of the last table accessed by the
security definer function just called, even if the user doesn't have
schema permission? I doubt!
Jan
I'm not sure it makes sense to be able to revoke someone's permissions
on an object they've already accessed. From a transactional point of
view, the revoke should at the very least not affect transactions
started prior to the revokation. Some things are shared across an
entire session, and the rule extends to them. Is this a bug? Maybe, but
it is debatable.Have a nice day,
--
#======================================================================#
# It's easier to get forgiveness for being wrong than for being right. #
# Let's break this rule - forgive me. #
#================================================== JanWieck@Yahoo.com #
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 <quote>look up</>
objects within the schema. Without this permission, it is still
possible to see the object names by querying the system tables, but
they cannot be accessed via SQL.
---------------------------------------------------------------------------
Jan Wieck wrote:
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
contain prepared statements, and many client applications cache
prepared
statements as well. Thus, revoking usage on a schema is about as
good as
nothing until all sessions have ended. It also means that any function
which operates with OIDs can potentially bypass the schema usage
check.The docs probably should elaborate that once something's been looked
up you no longer need permissions on the schema it resides in.I'm not sure this is really unexpected behaviour. On UNIX it is clearly
defined that file permissions are checked only on open. Once you've
opened it, changing permissions on the file won't affect you. If
someone passes you a read/write descriptor to a file, you can
read/write it even if you didn't have permissions to open the
file/socket/whatever yourself.This isn't the case and I do agree with Phil on this. The fact that
another "security definer" function did access an object during the
session should not give the user the ability to access it in the manner
shown in his example. lastval() without arguments should not remember
the sequence by its oid only, but also remember the sequences schema and
to a proper ACL check on that as well.Just think of it if SELECT without a FROM clause would automatically
assume the same rangetable as the last SELECT in the session. If that
were the case, would you guy's defend the position that "SELECT *" then
should spit out the full content of the last table accessed by the
security definer function just called, even if the user doesn't have
schema permission? I doubt!Jan
I'm not sure it makes sense to be able to revoke someone's permissions
on an object they've already accessed. From a transactional point of
view, the revoke should at the very least not affect transactions
started prior to the revokation. Some things are shared across an
entire session, and the rule extends to them. Is this a bug? Maybe, but
it is debatable.Have a nice day,
--
#======================================================================#
# It's easier to get forgiveness for being wrong than for being right. #
# Let's break this rule - forgive me. #
#================================================== JanWieck@Yahoo.com #---------------------------(end of broadcast)---------------------------
TIP 6: explain analyze is your friend
--
Bruce Momjian bruce@momjian.us
EnterpriseDB http://www.enterprisedb.com
+ If your life is a hard drive, Christ can be your backup. +
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 <quote>look up</>
objects within the schema. Without this permission, it is still
possible to see the object names by querying the system tables, but
they cannot be accessed via SQL.
No, this still misses the point entirely. See all my examples in this
thread for ways I have accessed objects without usage to their schema
with SQL.
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 this allows the grantee to <quote>look up</>
objects within the schema. Without this permission, it is still
possible to see the object names by querying the system tables, but
they cannot be accessed via SQL.No, this still misses the point entirely. See all my examples in this
thread for ways I have accessed objects without usage to their schema
with SQL.
OK, well we are not putting a huge paragraph in there. Please suggest
updated text.
--
Bruce Momjian bruce@momjian.us
EnterpriseDB http://www.enterprisedb.com
+ If your life is a hard drive, Christ can be your backup. +
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 the objects' own privilege requirements are
also met). Essentially this allows the grantee to <quote>look up</>
objects within the schema. Without this permission, it is still
possible to see the object names by querying the system tables, but
they cannot be accessed via SQL.No, this still misses the point entirely. See all my examples in this
thread for ways I have accessed objects without usage to their schema
with SQL.OK, well we are not putting a huge paragraph in there. Please suggest
updated text.
Well, if you won't explain the whole situation, nor change it, then all
you can really say is it doesn't really work always. How about this:
For schemas, allows access to objects contained in the specified
schema. Note that the converse is not true in many cases: revoking
usage on a schema is not sufficient to prevent access in all cases.
There is precedent for new ways to bypass this check being added in
future releases. It would be unwise to give this privilege much
security value.
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
schema (assuming that the objects' own privilege requirements are
also met). Essentially this allows the grantee to <quote>look up</>
objects within the schema. Without this permission, it is still
possible to see the object names by querying the system tables, but
they cannot be accessed via SQL.No, this still misses the point entirely. See all my examples in this
thread for ways I have accessed objects without usage to their schema
with SQL.OK, well we are not putting a huge paragraph in there. Please suggest
updated text.Well, if you won't explain the whole situation, nor change it, then all
you can really say is it doesn't really work always. How about this:For schemas, allows access to objects contained in the specified
schema. Note that the converse is not true in many cases: revoking
usage on a schema is not sufficient to prevent access in all cases.
There is precedent for new ways to bypass this check being added in
future releases. It would be unwise to give this privilege much
security value.
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 <quote>look up</>
objects within the schema. Without this permission, it is still
possible to see the object names, e.g. by querying the system tables,
so this is not a completely secure way to prevent object access.
--
Bruce Momjian bruce@momjian.us
EnterpriseDB http://www.enterprisedb.com
+ If your life is a hard drive, Christ can be your backup. +
