KaiGai Kohei wrote: > Robert Haas wrote: > >> Can you *do* the row-level permission? > > > > I don't think there's any consensus on a design. > > Yes, unfortunatelly. > No one replied to my proposed design: > http://marc.info/?l=pgsql-hackers&m=122222470930544&w=2
Yes, we got stuck on the covert channels issue. Frankly I think the use of non-natural keys addresses most of the covert channel issues and should be recommended for secure setups --- I don't think we are going to do any better than that and think we need to move forward on that assumption. We can cite http://citeseerx.ist.psu.edu/viewdoc/summary?doi=10.1.1.33.5950, which outlines the security risks. > > Getting consensus on a design seems to actually be one of the harder > > aspects of PostgreSQL development. The pattern seems to be: > > > > 1. Someone submits a patch. By definition, the patch embodies some > > particular design. > > 2. One or more members of core express concerns about the design > > embodied in the patch. > > 3. If the concerns are fairly specific and not mutually contradictory, > > the submitter revises the patch accordingly and it gets committed > > (hopefully without having to discard too much of their previous work). > > 4. If the concerns are fairly vague and open-ended, or if they > > contract each other, the patch hovers in limbo for eternity. > > > > I'm not sure what the solution to this problem is. The fact that a > > member of core does not like a particular design for feature X does > > not oblige that person to produce a better one, but it's pretty tough > > to proceed without it. Yes, see above --- I think it is time to move forward. > Yes, I have had similar experiences in Linux kernel development for > several years. > The amount of time to get consensus is one of the reason why I want > to move the SQL based row-level security to v8.5 development cycle. As I stated before, I think doing an SE-Linux version and then adding a more generalized solution is doing things in the wrong order because the generalized solution is going to have to re-do the SE-Linux stuff. As much as I would like to see SE-Linux support in 8.4, I think we need general column and row-level permission built with an eye on what SE-Linux will need, then add SE-Linux security. > > In the case of SE-PostgreSQL, two members of core expressed concerns: > > > > - Peter Eisentraut expressed concern about implementing row-level > > security via SE-PostgreSQL without first implementing some sort of > > SQL-based row-level security. KaiGai expressed willingness to > > implement that, but we still don't have a design, so I assume KaiGai > > is going to implement... something... and hope that it turns out to be > > acceptable. > > Its conclusion is actually not clear for me. > The proposed SQL based row-level security assumes what he pointed out > is right, but I don't know the reason why it should be placed prior. > > I guess he intend to share the code for row-level security, thus it > should be implemented prior to the OS specific feature. But most of > SE-PostgreSQL code is separated from core implementation and invoked > via security hooks, so it is unsuitable to share code with other > facilities. You are right based on line counts in the patch, but based on actual changes to the existing code, SE-Linux changes very much match what SQL-level permissions would need. > > - Tom Lane expressed concerns about covert channels to which KaiGai > > responded, AIUI, that the patch was pretty useful even without > > addressing that issue, but if Tom isn't willing to see the patch > > committed otherwise, then KaiGai has to decide between giving up and > > attempting to implement some form of polyinstantiation - which will > > not be easy, and which is far from guaranteed to be accepted if he > > does develop it. > > Its conclusion it not clear. > > I think the polyinstantiation is too much requirements, as prior major Agreed on polyinstantiation. > commercial RDBMS with row-level security (like Oracle Label Security) > does not care about such kind of covert channels. > It is quite natural to describe such kind of limitation/specification > on the documentation explicitly to help end-user's decision. Agreed. > > In both cases, the lack of a clear roadmap means that a dedicated > > developer is potentially putting in a lot of time and effort > > developing what may end up being a complete dead-end. > > I believe such a situation will help nobody get happy. I think we need to see a specification on how SQL-level row permissions would work, and get column-level permissions into CVS. To summarize, 70% of the SE-Linux patch is in stand-alone C files, which has little disruption, but 30% are changes to the core backend code, which will be disruptive, so we would like to have SQL-level permissions that everyone uses to be that disruption, and have SE-Linux attach to those capabilities. -- Bruce Momjian <[EMAIL PROTECTED]> http://momjian.us EnterpriseDB http://enterprisedb.com + If your life is a hard drive, Christ can be your backup. + -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers