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 tablespace size.
Yeah --- we do have a "usage" permission for tablespaces but it's not
clear that that should extend to letting people deduce info about other
databases.
> On the other hand, how useful is the information that a tablespace is 35GB
> in size and that includes 16GB of stuff you're not allowed to see? Are we
> hypothesizing that some attacker would not have CONNECT on a DB, but would
> know exactly which tables that DB stores on which tablespace? This seems
> very corner-case.
No, it's exactly the sort of "side channel" that blackhats look for all
the time. For instance, many of openssl's recent security fixes have
been about closing ways to infer what the program is doing from
secondary information, like how long it takes to respond.
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? It's analogous to saying that we don't
try to protect system catalog contents, which is a policy that we've
held to but it's a frequent source of complaints. Also, we do have one
answer for people who complain about that: give mutually untrusting
users separate databases. The functions at issue here give some
visibility into other databases, with *no* recourse for someone who
finds that unhappy-making, short of running multiple postmasters
(which is a pretty inefficient solution).
regards, tom lane
---------------------------(end of broadcast)---------------------------
TIP 2: Don't 'kill -9' the postmaster
