AW: [HACKERS] Isn't pg_statistic a security hole?
Right now anyone can look in pg_statistic and discover the min/max/most common values of other people's tables. That's not a lot of info, but it might still be more than you want them to find out. And the statistical changes that I'm about to commit will allow a couple dozen values to be exposed, not only three values per column. It seems to me that only superusers should be allowed to read the pg_statistic table. Or am I overreacting? Comments? You are not overreacting. Imagine a salary column. I can imagine max/min being quite interesting. I doubt it is worth letting non-super users see values in that table. Their only value is in debugging the optimizer, which seems like a super-user job anyway. How about letting them see all statistics where they have select permission on the base table (if that is possible with the new permission table) ? Andreas ---(end of broadcast)--- TIP 6: Have you searched our list archives? http://www.postgresql.org/search.mpl
Re: AW: [HACKERS] Isn't pg_statistic a security hole?
Zeugswetter Andreas SB [EMAIL PROTECTED] writes: How about letting them see all statistics where they have select permission on the base table (if that is possible with the new permission table) ? Yeah, I was thinking the same thing. If we restrict the view on the basis of current_user being the owner, then we'd have the annoying problem that superusers *couldn't* use the view for tables they didn't own. To implement this, we'd need a SQL function that answers the question does user A have read permission on table B?, which is something that people have asked for in the past anyway. (The existing SQL functions for manipulating ACLs are entirely unhelpful for determining this.) Someone needs to come up with a spec for such a function --- do we specify user and table by names or by OIDs, how is the interesting permission represented, etc. Is there anything comparable defined by SQL99 or in other DBMSes? regards, tom lane ---(end of broadcast)--- TIP 6: Have you searched our list archives? http://www.postgresql.org/search.mpl
Re: [HACKERS] Isn't pg_statistic a security hole?
Tom Lane wrote: Serguei Mokhov [EMAIL PROTECTED] writes: Being a simple user, I still want to view the stats from the table, but it should be limited only to the stuff I own. I don't wanna let others see any of my info, however. The SU's, of course, should be able to read all the stats. This is infeasible since we don't have a concept of per-row permissions. It's all or nothing. Can't we provide a view that shows those rows from pg_statistics that belong to the tables owned by the current user? Jan -- #==# # It's easier to get forgiveness for being wrong than for being right. # # Let's break this rule - forgive me. # #== [EMAIL PROTECTED] # _ Do You Yahoo!? Get your free @yahoo.com address at http://mail.yahoo.com ---(end of broadcast)--- TIP 6: Have you searched our list archives? http://www.postgresql.org/search.mpl
Re: [HACKERS] Isn't pg_statistic a security hole?
Bruce Momjian [EMAIL PROTECTED] writes: It seems to me that only superusers should be allowed to read the pg_statistic table. Or am I overreacting? Comments? You are not overreacting. Imagine a salary column. I can imagine max/min being quite interesting. A fine example, indeed ;-) I doubt it is worth letting non-super users see values in that table. Their only value is in debugging the optimizer, which seems like a super-user job anyway. Well, mumble. I routinely ask people who're complaining of bad plans for extracts from their pg_statistic table. I don't foresee that need vanishing any time soon :-(. The idea of a view seemed nice, in part because it could be set up to give all the useful info with a simple select * from pg_statview where relname = 'foo'; rather than the messy three-way join you have to type now. regards, tom lane ---(end of broadcast)--- TIP 6: Have you searched our list archives? http://www.postgresql.org/search.mpl
[HACKERS] Isn't pg_statistic a security hole?
Right now anyone can look in pg_statistic and discover the min/max/most common values of other people's tables. That's not a lot of info, but it might still be more than you want them to find out. And the statistical changes that I'm about to commit will allow a couple dozen values to be exposed, not only three values per column. It seems to me that only superusers should be allowed to read the pg_statistic table. Or am I overreacting? Comments? regards, tom lane ---(end of broadcast)--- TIP 4: Don't 'kill -9' the postmaster
Fw: [HACKERS] Isn't pg_statistic a security hole?
Sorry, forgot to post to the list... - Original Message - From: Tom Lane [EMAIL PROTECTED] Serguei Mokhov [EMAIL PROTECTED] writes: Being a simple user, I still want to view the stats from the table, but it should be limited only to the stuff I own. I don't wanna let others see any of my info, however. The SU's, of course, should be able to read all the stats. This is infeasible since we don't have a concept of per-row permissions. It's all or nothing. How hard is to create a per-user stats table similar to pg_statistic? And then limit the original pg_statistic table only to superusers... OR when one queries the table, this one can be authenticated and even if there are no per-row permissions, it is possible to output one row WHERE the username is the same as the user runs the query. Isn't it the same like SELECT * FROM pg_statisctic WHERE 'user is myself' and this WHERE clause will be just appended by the system for the current user to the original query. Does it make any sense, is it sane? Cuz, I'm not familiar with PG internals at all... Serguei ---(end of broadcast)--- TIP 4: Don't 'kill -9' the postmaster
Re: [HACKERS] Isn't pg_statistic a security hole?
Serguei Mokhov [EMAIL PROTECTED] writes:
Being a simple user, I still want to view the stats from the table,
but it should be limited only to the stuff I own. I don't wanna let
others see any of my info, however. The SU's, of course, should be
able to read all the stats.
This is infeasible since we don't have a concept of per-row permissions.
It's all or nothing.
You can acheive the same effect using a view if the statistics table has the
user name included.
Joe
test=# select version();
version
---
PostgreSQL 7.1 on i686-pc-linux-gnu, compiled by GCC 2.96
(1 row)
create table teststat(username name,stat_id int4,stat_val float, primary
key(username,stat_id));
NOTICE: CREATE TABLE/PRIMARY KEY will create implicit index 'teststat_pkey'
for table 'teststat'
CREATE
insert into teststat values('postgres',1,15.321);
INSERT 1007064 1
insert into teststat values('foo',1,12.123);
INSERT 1007065 1
select * from teststat;
username | stat_id | stat_val
--+-+--
postgres | 1 | 15.321
foo | 1 | 12.123
(2 rows)
create view vw_teststat as (select * from teststat where
(username=current_user or current_user='postgres'));
CREATE
select current_user;
current_user
--
postgres
(1 row)
select * from vw_teststat;
username | stat_id | stat_val
--+-+--
postgres | 1 | 15.321
foo | 1 | 12.123
(2 rows)
create user foo;
CREATE USER
grant select on vw_teststat to foo;
CHANGE
You are now connected as new user foo.
select current_user;
current_user
--
foo
(1 row)
select * from vw_teststat;
username | stat_id | stat_val
--+-+--
foo | 1 | 12.123
(1 row)
---(end of broadcast)---
TIP 3: if posting/reading through Usenet, please send an appropriate
subscribe-nomail command to [EMAIL PROTECTED] so that your
message can get through to the mailing list cleanly
Re: [HACKERS] Isn't pg_statistic a security hole?
Stephan Szabo [EMAIL PROTECTED] writes: This is infeasible since we don't have a concept of per-row permissions. It's all or nothing. Maybe make statistics readable only by superusers with a view that uses CURRENT_USER or something like that to only give the objects that have owners of this user? Might be an ugly view, but... Hmm, that would work --- you could join against pg_class to find out the owner of the relation. While you were at it, maybe look up the attribute name in pg_attribute as well. Anyone want to propose a specific view definition? regards, tom lane ---(end of broadcast)--- TIP 2: you can get off all lists at once with the unregister command (send unregister YourEmailAddressHere to [EMAIL PROTECTED])
Re: [HACKERS] Isn't pg_statistic a security hole?
Hmm, that would work --- you could join against pg_class to find out the owner of the relation. While you were at it, maybe look up the attribute name in pg_attribute as well. Anyone want to propose a specific view definition? How does this work? create view pg_userstat as ( select s.starelid ,s.staattnum ,s.staop ,s.stanullfrac ,s.stacommonfrac ,s.stacommonval ,s.staloval ,s.stahival ,c.relname ,a.attname ,sh.usename from pg_statistic as s ,pg_class as c ,pg_shadow as sh ,pg_attribute as a where (sh.usename=current_user or current_user='postgres') and sh.usesysid = c.relowner and a.attrelid = c.oid and c.oid = s.starelid ); -- Joe ---(end of broadcast)--- TIP 4: Don't 'kill -9' the postmaster
