Re: [RFC] Security label support
От | Robert Haas |
---|---|
Тема | Re: [RFC] Security label support |
Дата | |
Msg-id | AANLkTikvgjCNneKYtI0RthbL2okVdlJnu7OQnsAxhHzz@mail.gmail.com обсуждение исходный текст |
Ответ на | Re: [RFC] Security label support (Tom Lane <tgl@sss.pgh.pa.us>) |
Ответы |
Re: [RFC] Security label support
(KaiGai Kohei <kaigai@ak.jp.nec.com>)
|
Список | pgsql-hackers |
On Thu, May 27, 2010 at 4:01 PM, Tom Lane <tgl@sss.pgh.pa.us> wrote: > Stephen Frost <sfrost@snowman.net> writes: >> * Tom Lane (tgl@sss.pgh.pa.us) wrote: >>> I'm not real sure that you want a dependency for a security label anyway >>> --- wouldn't that mean each label could only be used for one object? > >> Err, your question comes across to me like "if you added comments to >> pg_depend, you'd only be able to use a given comment X for one object?". >> Doesn't make alot of sense. :) > > Well, one of us is confused. I thought the idea was that the same > security label would apply to many different objects. If each object > has its own label, you're going to need an awfully large label cache > for performance to be sane. I think this only makes sense when and if we implement row-level security. The labels for SELinux are, say, 64 byte strings. That's really not that big, if these are only being applied to objects like tables, and even columns. More to the point, ISTM a cache would be fairly useless anyway, because you have to pass the labels themselves to the OS to get an access control decision, which is also based on the type of object that you're doing something to and the operation you're doing to it. It probably make sense to cache the results of the access-control lookup within a query - for example, if all the labels of a table you're accessing have the same label, just ask once for all of them, instead of individually for each one - but I can't see how you could usefully do much more than that. Now, if we were talking about row-level security, well, that's a whole different situation. Now the space to store the individual labels might become burdensome. But that's a problem for another day, hopefully a day when I'm out of town. >> The structure for pg_seclabel we were talking about would be very >> similar to pg_description, eg: > >> CREATE TABLE pg_seclabel ( >> objoid oid not null, >> classoid oid not null, >> objsubid integer not null, >> label text >> ); > >> We could move label into another table (eg: pg_labels) and then give an >> OID to each label and then store the label's OID in pg_seclabel. > > OK, but the notion that you would try to remove "orphan" pg_labels > entries seems entirely wrongheaded to me. The labels would be > long-lived objects. Now I'm confused. Previously you complained about not having a garbage collection mechanism for labels - now you seem to be saying that we should never garbage collect. -- Robert Haas EnterpriseDB: http://www.enterprisedb.com The Enterprise Postgres Company
В списке pgsql-hackers по дате отправления: