Skip site navigation (1) Skip section navigation (2)

Re: SE-PgSQL developer documentation (Re: Reworks for Access Control facilities (r2363))

From: Alvaro Herrera <alvherre(at)commandprompt(dot)com>
To: KaiGai Kohei <kaigai(at)ak(dot)jp(dot)nec(dot)com>
Cc: Heikki Linnakangas <heikki(dot)linnakangas(at)enterprisedb(dot)com>,Robert Haas <robertmhaas(at)gmail(dot)com>,KaiGai Kohei <kaigai(at)kaigai(dot)gr(dot)jp>, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>,Stephen Frost <sfrost(at)snowman(dot)net>, pgsql-hackers(at)postgresql(dot)org
Subject: Re: SE-PgSQL developer documentation (Re: Reworks for Access Control facilities (r2363))
Date: 2009-10-28 13:27:46
Message-ID: 20091028132746.GC5018@alvh.no-ip.org (view raw or flat)
Thread:
Lists: pgsql-hackers
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.

Now, let's assume that COPY data includes the security context for each
tuple in the output.  How is that data restored?  Would you need to
grant super-SEPostgres privileges to the user restoring the data?

-- 
Alvaro Herrera                                http://www.CommandPrompt.com/
PostgreSQL Replication, Consulting, Custom Development, 24x7 support

In response to

Responses

pgsql-hackers by date

Next:From: Tom LaneDate: 2009-10-28 13:43:48
Subject: Re: Where's the docs?
Previous:From: KaiGai KoheiDate: 2009-10-28 13:27:12
Subject: Re: SE-PgSQL developer documentation (Re: Reworks for Access Control facilities (r2363))

Privacy Policy | About PostgreSQL
Copyright © 1996-2014 The PostgreSQL Global Development Group