Simon Riggs wrote: > Some initial thoughts based upon reading the Wiki. I've not been > involved in things up to now, so if this dredges up old discussions, > well, these are my thoughts. > > I want SEPostgreSQL, but I'd like it to work without needing to be a > compile time option so people can just use it as/when needed. Plus we > don't want to support what would be/is essentially a fork of Postgres. > Most CPUs will optimise away a simple if-test in various places.
Well, I assume SEPostgreSQL will rely on libraries that only exist on SELinux, so I am afraid there will have to be some type of compile-time flag, though the goal is to have as much of it enabled as possible at the SQL level, as we have discussed and the patch reflects. > Some users will be able to take advantage of the facilities without > implementing full MLS. Yet we want the full facilities for Government. > Many people currently run multiple customers in different schemas, > though this would let them just run a single set of tables so is much > better for running many small customers. > > I'm very unhappy about putting a nonoptional value on tuple headers, > especially because it is updatable. Do we expect MVCC will work with > updatable security contexts? i.e. when you update the security context > of a tuple that won't effect its visibility to existing system users. I > can't imagine you'd want that would you? It's kind of difficult to *not* > get it though. > > Looks to me that this feature is useless without things working at row > level. So we can't leave that part out. Having the security column be optional is an interesting idea, perhaps like we do with oids and with a GUC variable controlling the default. I think the patch itself is going to go through many adjustments before application, I bet. > The security context on each row could be an optional column present > only if HEAP_HASSECURITYCONTEXT is set (0x0010 see htup.h), just like > OIDs. Use a specific datatype rather than TEXT. That datatype could be > an identifier to pg_security. Security people have big databases too, so > we need to compress the security context more and take out parse time of > string handling. Don't think we should use Oids, they're too big. Might > be easier to use a 2byte field and restrict access to 32,000 contexts, > which is easily enough. TEXT also makes me nervous, just in case there > is some collation/encoding weirdness that allows contexts to be > subverted. Fixed integers are hard to compromise in that respect. I think the security mechanism is more complex than just assigning a single security identifier, but perhaps not; I am unsure. > How will unique indexes work? Do you implicitly add security context as > last column on every unique index, or does the uniqueness violation only > occurs within security contexts, or does the uniqueness violation tested > against all contextx that the inserter can currently see? Is there a > change to system catalogs? > > Foreign Key deletions could be handled correctly if you treat them as > updates. If we have the following example > > TableA > security_context=y value=2 fk=1 > > TableB > security_context=x value=1 > > TableA refers to TableB. Context x cannot see context y. I think this is the "covert channel" we have been discussing. > The interaction with SELinux should not be hardcoded. I think we need > some form of plugin/wrapper to allow other systems to work. Not sure > what those are, but this isn't a Linux only project. We want to give > everybody the ability to work with PostgreSQL. I think that is why the text security column was used, so other systems could put their own security text in there. -- Bruce Momjian <[EMAIL PROTECTED]> http://momjian.us EnterpriseDB http://enterprisedb.com + If your life is a hard drive, Christ can be your backup. + -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers