sepgsql: fix relkind handling on foreign tables
The attached patch fixes up case handling in foreign tables.
Now it didn't assign security label on foreign table on its creation
time, and didn't check access rights on the dml hook.
This patch fixes these problems; It allows foreign tables default
labeling and access checks as db_table object class.
Thanks,
--
KaiGai Kohei <kaigai@kaigai.gr.jp>
Attachments:
sepgsql-fix-foreign-table.1.patchapplication/octet-stream; name=sepgsql-fix-foreign-table.1.patchDownload
contrib/sepgsql/dml.c | 3 ++-
contrib/sepgsql/label.c | 7 +++++--
contrib/sepgsql/relation.c | 17 ++++++++++++-----
3 files changed, 19 insertions(+), 8 deletions(-)
diff --git a/contrib/sepgsql/dml.c b/contrib/sepgsql/dml.c
index 22666b7..d89dcd0 100644
--- a/contrib/sepgsql/dml.c
+++ b/contrib/sepgsql/dml.c
@@ -189,6 +189,7 @@ check_relation_privileges(Oid relOid,
switch (relkind)
{
case RELKIND_RELATION:
+ case RELKIND_FOREIGN_TABLE:
result = sepgsql_check_perms(scontext,
tcontext,
SEPG_CLASS_DB_TABLE,
@@ -228,7 +229,7 @@ check_relation_privileges(Oid relOid,
/*
* Only columns owned by relations shall be checked
*/
- if (relkind != RELKIND_RELATION)
+ if (relkind != RELKIND_RELATION && relkind != RELKIND_FOREIGN_TABLE)
return true;
/*
diff --git a/contrib/sepgsql/label.c b/contrib/sepgsql/label.c
index 669ee35..c879d57 100644
--- a/contrib/sepgsql/label.c
+++ b/contrib/sepgsql/label.c
@@ -323,6 +323,7 @@ exec_object_restorecon(struct selabel_handle * sehnd, Oid catalogId)
int objtype = 1234;
ObjectAddress object;
security_context_t context;
+ char relkind;
/*
* The way to determine object name depends on object classes. So, any
@@ -347,7 +348,8 @@ exec_object_restorecon(struct selabel_handle * sehnd, Oid catalogId)
case RelationRelationId:
relForm = (Form_pg_class) GETSTRUCT(tuple);
- if (relForm->relkind == RELKIND_RELATION)
+ if (relForm->relkind == RELKIND_RELATION ||
+ relForm->relkind == RELKIND_FOREIGN_TABLE)
objtype = SELABEL_DB_TABLE;
else if (relForm->relkind == RELKIND_SEQUENCE)
objtype = SELABEL_DB_SEQUENCE;
@@ -371,7 +373,8 @@ exec_object_restorecon(struct selabel_handle * sehnd, Oid catalogId)
case AttributeRelationId:
attForm = (Form_pg_attribute) GETSTRUCT(tuple);
- if (get_rel_relkind(attForm->attrelid) != RELKIND_RELATION)
+ relkind = get_rel_relkind(attForm->attrelid);
+ if (relkind != RELKIND_RELATION && relkind != RELKIND_FOREIGN_TABLE)
continue; /* no need to assign security label */
objtype = SELABEL_DB_COLUMN;
diff --git a/contrib/sepgsql/relation.c b/contrib/sepgsql/relation.c
index 963cfdf..00eb194 100644
--- a/contrib/sepgsql/relation.c
+++ b/contrib/sepgsql/relation.c
@@ -39,13 +39,15 @@ sepgsql_attribute_post_create(Oid relOid, AttrNumber attnum)
char *scontext = sepgsql_get_client_label();
char *tcontext;
char *ncontext;
+ char relkind;
ObjectAddress object;
/*
* Only attributes within regular relation have individual security
* labels.
*/
- if (get_rel_relkind(relOid) != RELKIND_RELATION)
+ relkind = get_rel_relkind(relOid);
+ if (relkind != RELKIND_RELATION && relkind != RELKIND_FOREIGN_TABLE)
return;
/*
@@ -82,9 +84,11 @@ sepgsql_attribute_relabel(Oid relOid, AttrNumber attnum,
char *scontext = sepgsql_get_client_label();
char *tcontext;
char *audit_name;
+ char relkind;
ObjectAddress object;
- if (get_rel_relkind(relOid) != RELKIND_RELATION)
+ relkind = get_rel_relkind(relOid);
+ if (relkind != RELKIND_RELATION && relkind != RELKIND_FOREIGN_TABLE)
ereport(ERROR,
(errcode(ERRCODE_WRONG_OBJECT_TYPE),
errmsg("cannot set security label on non-regular columns")));
@@ -160,7 +164,8 @@ sepgsql_relation_post_create(Oid relOid)
classForm = (Form_pg_class) GETSTRUCT(tuple);
- if (classForm->relkind == RELKIND_RELATION)
+ if (classForm->relkind == RELKIND_RELATION ||
+ classForm->relkind == RELKIND_FOREIGN_TABLE)
tclass = SEPG_CLASS_DB_TABLE;
else if (classForm->relkind == RELKIND_SEQUENCE)
tclass = SEPG_CLASS_DB_SEQUENCE;
@@ -190,7 +195,8 @@ sepgsql_relation_post_create(Oid relOid)
* We also assigns a default security label on columns of the new regular
* tables.
*/
- if (classForm->relkind == RELKIND_RELATION)
+ if (classForm->relkind == RELKIND_RELATION ||
+ classForm->relkind == RELKIND_FOREIGN_TABLE)
{
AttrNumber index;
@@ -234,7 +240,8 @@ sepgsql_relation_relabel(Oid relOid, const char *seclabel)
uint16_t tclass = 0;
relkind = get_rel_relkind(relOid);
- if (relkind == RELKIND_RELATION)
+ if (relkind == RELKIND_RELATION ||
+ relkind == RELKIND_FOREIGN_TABLE)
tclass = SEPG_CLASS_DB_TABLE;
else if (relkind == RELKIND_SEQUENCE)
tclass = SEPG_CLASS_DB_SEQUENCE;
On Sun, May 22, 2011 at 5:52 AM, Kohei KaiGai <kaigai@kaigai.gr.jp> wrote:
The attached patch fixes up case handling in foreign tables.
Now it didn't assign security label on foreign table on its creation
time, and didn't check access rights on the dml hook.
This patch fixes these problems; It allows foreign tables default
labeling and access checks as db_table object class.
A foreign table is really more like a view, or a function call. Are
you sure you want to handle it like a table?
--
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company
2011/5/23 Robert Haas <robertmhaas@gmail.com>:
On Sun, May 22, 2011 at 5:52 AM, Kohei KaiGai <kaigai@kaigai.gr.jp> wrote:
The attached patch fixes up case handling in foreign tables.
Now it didn't assign security label on foreign table on its creation
time, and didn't check access rights on the dml hook.
This patch fixes these problems; It allows foreign tables default
labeling and access checks as db_table object class.A foreign table is really more like a view, or a function call. Are
you sure you want to handle it like a table?
It might be a tentative solution, so I'll want to cancel this patch.
Its nature is indeed more similar to function call rather than tables,
but not a function itself. So, it might be a better idea to define its
own object class such as "db_foreign_table" instead of existing
object classes.
Thanks,
--
KaiGai Kohei <kaigai@kaigai.gr.jp>
On Tue, May 24, 2011 at 6:57 AM, Kohei KaiGai <kaigai@kaigai.gr.jp> wrote:
2011/5/23 Robert Haas <robertmhaas@gmail.com>:
On Sun, May 22, 2011 at 5:52 AM, Kohei KaiGai <kaigai@kaigai.gr.jp> wrote:
The attached patch fixes up case handling in foreign tables.
Now it didn't assign security label on foreign table on its creation
time, and didn't check access rights on the dml hook.
This patch fixes these problems; It allows foreign tables default
labeling and access checks as db_table object class.A foreign table is really more like a view, or a function call. Are
you sure you want to handle it like a table?It might be a tentative solution, so I'll want to cancel this patch.
Its nature is indeed more similar to function call rather than tables,
but not a function itself. So, it might be a better idea to define its
own object class such as "db_foreign_table" instead of existing
object classes.
Perhaps. Or else use db_view.
--
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company