Alvaro Herrera wrote:
KaiGai Kohei escribió:
There are two cases when we create a new object.
1) create a new object without any explicit security context.
If we don't have statement support, it is the only case.
In this case, SELinux computes a default security context to be assigned
on the new object. It depends on the client's security context.
Then, it checks "create" permission on a pair of the client's security
context and the default security context. If not allowed, an error will
be raised.
So, following this path, it is possible to write pg_dump support without
a explicit security contexts: you have to make pg_dump write out the
different tuples under different users. So you'd have more than one
data object in the dump output for each table, one for every existing
security context. This seems extremely difficult and intrusive however.
It seems that having explicit security contexts in statements is
necessary for this area to be reasonably simple.
Yes, it may be possible to restore the tables without statement, if we switch
OS-user's privilege for each tables, but unreasonable and unrealistic.
Now, let's assume that COPY data includes the security context for each
tuple in the output.
When we support row-level security, it will be necessary to backup and
restore the security context for each tuples.
What I'm talking about is how we specify the security context of the new
tables. If we can have statement support, it will be specified as follows:
CREATE TABLE t ( a int primary key, b text)
SECURITY_CONTEXT = 'system_u:object_r:sepgsql_ro_table_t:unclassified';
How is that data restored? Would you need to
grant super-SEPostgres privileges to the user restoring the data?
We need to restore the backup by the user who has privileges to create
database objects dumped at least. But no needs to have super-privilege.
For example, if all the dumped table are labeled as either "unclassified"
or "classified" but not "secret", all the needed privilege is to create
"unclassified" and "classified" tables, not "secret" table.
However, I expect that "unconfined" domain does the backup/restore works
expect for especially secure system. I don't think the default security
policy (such as ones bundled with Fedora) should restrict DBA's privileges
connected from the shell process.
Thanks,
--
KaiGai Kohei <kai...@kaigai.gr.jp>
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
