2010/8/9 <kai...@kaigai.gr.jp>: >> 2. Some of this code refers to "local" security labels. I'm not sure >> what's "local" about them - aren't they just security labels? On a >> related note, I don't like the trivial wrappers you have here, with >> DeleteSecurityLabel around DeleteLocalSecLabel, SetSecurityLabel >> around SetLocalSecLabel, etc. Just collapse these into a single set >> of functions. >> > In the feature, I plan to assign security labels on the shared database > objects such as pg_database. The "local" is a contradistinction > towards these "shared" objects.
Oh, I see. I don't think that's entirely clear: and in any event it seems a bit premature, since we're not at that point yet. Let's just get rid of this stuff for now as I suggested. >> 5. Why do we think that the relabel hook needs to be passed the number >> of expected parents? >> > We need to prevent relabeling on inherited relations/columns from > the multiple origin, like ALTER RENAME TO. > It requires to pass the expected parents into the provider, or > to check it in the caller. Please explain further. I don't understand. >> 6. What are we doing about the assignment of initial security labels? >> I had initially thought that perhaps new objects would just start out >> unlabeled, and the user would be responsible for labeling them as >> needed. But maybe we can do better. Perhaps we should extend the >> security provider hook API with a function that gets called when a >> labellable object gets created, and let each loaded security provider >> return any label it would like attached. Even if we don't do that >> now, esp_relabel_hook_entry needs to be renamed to something more >> generic; we will certainly want to add more fields to that structure >> later. >> > Starting with "unlabeled" is wrong, because it does not distinguish > an object created by security sensitive users and insensitive users, > for example. It is similar to relation's relowner is InvalidOid. > > I plan the security provider hook on the creation time works two things. > 1. It checks user's privilege to create this object. > 2. It returns security labels to be assigned. > > Then, the caller assigns these returned labels on the new object, > if one or more valid labels are returned. OK, let's give that a try and see how it looks. I don't think that's in this version of the patch, right? >> 7. I think we need to write and include in the fine documentation some >> "big picture" documentation about enhanced security providers. Of >> course, we have to decide what we want to say. But the SECURITY LABEL >> documentation is just kind of hanging out there in space right now; it >> needs to connect to a broad introduction to the subject. >> > OK, I'll try to describe with appropriate granularity. > Do we need an independent section in addition to the introduction of > SECURITY LABEL syntax? I think so. I suggest a new chapter called "Enhanced Security Providers" just after "Database Roles and Privileges". > BTW, I'll go on the area where internet unconnectable during next > two days. Perhaps, my reply will run late. No problem. -- Robert Haas EnterpriseDB: http://www.enterprisedb.com The Enterprise Postgres Company -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
