On Tuesday 28 August 2007 15:38, Tom Lane wrote:
Therefore, I propose the same choices as before for table-size (no
restriction) and database-size (must have CONNECT priv), and this
for tablespace-size: you must have the ability to create tables in
the target tablespace. This could be either
Tom Lane wrote:
btreefuncs.c is a security hole a mile wide: it will happily dump the
entire data content of an index for you. It's a good thing this hasn't
shipped in any release yet. While we could possibly make it look up
the index's parent table and check if you have SELECT privilege on
Josh Berkus [EMAIL PROTECTED] writes:
Well, that puts us back in the position of requiring a read or metadata
permission for tablespaces, or requiring superuser access. The latter is
unpalatable because there are existing tools in the field which work without
superuser access; the former
Tom,
... in particular, that restriction seems pretty content-free for most
practical layouts. And it's got interesting security behaviors:
DBA A, by more-or-less innocently allowing some tables in his database B
to be created in tablespace C, might be allowing his unrelated user D to
find
Tom Lane wrote:
* no restriction on database-size function *when applied to the current
database* (again, you could look into pg_class); to apply to some other
database, you must have connect privileges. (Actually, on the
assumption that you must have connect privs to current DB, I guess we
Dave Page [EMAIL PROTECTED] writes:
Tom Lane wrote:
* tablespace-size function requires being owner of current DB.
I assume superusers will also be able to use it, not just the actual owner?
Right --- it'd be an ownercheck call which means that superusers and
anyone who's been granted
We seem to be down to arguing about what permissions are needed to
execute the tablespace-size functions. I wrote:
* tablespace-size function requires being owner of current DB.
There is nothing particularly principled about the last choice, but
it's not superuser and not wide open either.
Heikki Linnakangas [EMAIL PROTECTED] writes:
Tom Lane wrote:
btreefuncs.c is a security hole a mile wide: it will happily dump the
entire data content of an index for you. It's a good thing this hasn't
shipped in any release yet. While we could possibly make it look up
the index's parent
Tom,
dblink_get_pkey() will tell you what its primary key is. This is not
a big deal seeing that you can get the info by looking into the system
catalogs, but someone who was trying to lock down the system catalogs
wouldn't be happy. I think this should require SELECT privilege on
the
Josh Berkus [EMAIL PROTECTED] writes:
pgrowlocks tells you about row lock states, which maybe is not that
interesting for security, but still it's information that one wouldn't
expect to be exposed to someone who isn't allowed to read the table.
I suppose knowing the number of live tuples
Tom,
That's OK for individual tables, but we have no equivalent concept for
whole databases or tablespaces. What do you propose for them?
CONNECT, of course. There are no permissions for tablespaces except
CREATE, so presumably if the user can connect to the db, they ought to be
able to
Josh Berkus [EMAIL PROTECTED] writes:
Tom,
That's OK for individual tables, but we have no equivalent concept for
whole databases or tablespaces. What do you propose for them?
CONNECT, of course. There are no permissions for tablespaces except
CREATE, so presumably if the user can connect
Tom,
Another idea is to not hardwire any restriction into the C code, but
instead have initdb revoke the default public execute access on the
tablespace size function. It would still work for superusers, and
a particular DBA could choose to grant execute to trustworthy people.
The problem
Josh Berkus [EMAIL PROTECTED] writes:
Yeah, the big issue here is that Tablespaces do not have any kind of read
permission, so there's nothing for us to go by. There's a good reason for
them not to, since they're orthagonal to schema and databases, but it
leaves us without a handle for
Josh Berkus [EMAIL PROTECTED] writes:
Hmmm ... execept we're not requiring even permission on *one* DB in the
tablespace are we?
The status-quo-ante was that any user could get the number for any
database and/or any tablespace. I'm prepared to admit that what I
committed is too strong, but no
Tom,
Now you can argue that approximate database size information simply
isn't that useful to an attacker, and maybe that's true. But are
we prepared to make a policy decision that we aren't going to try to
protect such information at all?
But it's not making *no* attempt. This is a
I noticed a number of functions, most but not all in contrib, which
allow an unprivileged user to obtain varying amounts of information
about a relation he has no permissions to access:
dblink_get_pkey() will tell you what its primary key is. This is not
a big deal seeing that you can get the
Tom Lane [EMAIL PROTECTED] writes:
Lastly, int4notin() and oidnotin() have no permission checking, which
means you can find out whether specific values are or are not present
in an int4 or oid column you shouldn't read. This code is so old,
crufty, and undocumented that I'm strongly inclined
18 matches
Mail list logo
