Re: Updates of SE-PostgreSQL 8.4devel patches
От | Bruce Momjian |
---|---|
Тема | Re: Updates of SE-PostgreSQL 8.4devel patches |
Дата | |
Msg-id | 200809262215.m8QMFke11438@momjian.us обсуждение исходный текст |
Ответ на | Re: Updates of SE-PostgreSQL 8.4devel patches (Tom Lane <tgl@sss.pgh.pa.us>) |
Ответы |
Re: Updates of SE-PostgreSQL 8.4devel patches
Re: Updates of SE-PostgreSQL 8.4devel patches |
Список | pgsql-hackers |
Tom Lane wrote: > "Robert Haas" <robertmhaas@gmail.com> writes: > > I think you have to resign yourself to the fact that a user who can > > see only a subset of the rows in a table may very well see apparent > > foreign-key violations. But so what? > > So you're leaking information about the rows that they're not supposed > to be able to see. This is not what I would call national-security-grade > information hiding --- leastwise *I* certainly wouldn't store nuclear > weapon design information in such a database. The people that the NSA > wants to defend against are more than smart enough, and persistent > enough, to extract information through such loopholes. > > I can't escape the lurking suspicion that some bright folk inside the > NSA have spent years thinking about this and have come up with some > reasonably self-consistent definition of row hiding in a SQL database. > But have they published it where we can find it? I am confused how knowing that a sequence number used for a primary key exists or doesn't exist is leaking _meaningful_ information. People might know the sequence number exists, but how is that information useful. Now, if natural keys are used, that is a different story. I am, of course, supportive of digging deeper to find the best possible behavior. I am also supportive of making row-level security an SQL-level feature that can be used beyond SE-Linux, and will allow the feature to be tested on all platforms. -- Bruce Momjian <bruce@momjian.us> http://momjian.us EnterpriseDB http://enterprisedb.com + If your life is a hard drive, Christ can be your backup. +
В списке pgsql-hackers по дате отправления: