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 eith
"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
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.
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
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 w
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
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
> f
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
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
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 sp
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
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 probl
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
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 s
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 tu
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
"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 i
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 inf
18 matches
Mail list logo
