Use security labels for table configuration. #83
Conversation
Also simplifies sensitive relation info by dropping unused fields.
|
Ready for review. |
|
|
|
Also appears that there's a global We'll handle this later. |
I found that one, but it requires a name, which I don't have.
This is interesting, thanks! |
src/auth.c
Outdated
|
|
||
| if (seclabel == NULL) | ||
| { | ||
| ObjectAddress object = {.classId = NamespaceRelationId, .objectId = namespace_oid, .objectSubId = 0}; |
There was a problem hiding this comment.
I like this idea of permission inheritance!
Could we avoid shadowing and instead call these something like relation_object and namespace_object?
| else if (is_public_label(seclabel)) | ||
| return false; | ||
| else | ||
| FAILWITH_CODE(ERRCODE_INVALID_NAME, "'%s' is not a valid label", seclabel); |
There was a problem hiding this comment.
Does the compiler complain about a missing return in this branch?
There was a problem hiding this comment.
It doesn't. I think it detects that it performs an abort(), so it is a noreturn function.
Security labels are a pretty nice fit for table configuration.
We now associate the needed info directly with the objects of interest, without needing to worry about cleaning that info when the object is dropped or updating it when the object gets renamed.
For now, tables and namespaces can be marked as "sensitive" or "public". Unlabeled relations are considered public.
I wanted to add a third layer of labeling on the database level, but I didn't know how to get the database
Oid, so I left it for another time.The mechanism seems flexible enough, so additional information can be easily included into the labels.
It can also be extended for other purposes, like configuring what functions are allowed or not, for example.
This PR also does some refactoring to increase the separation between modules and drops some unused fields.