KaiGai Kohei wrote: > Bruce Momjian wrote: > > Bruce Momjian wrote: > >> Second, system catalogs; are you going to have separate columns for > >> SQL-level row security and SE-Linux security? If so, is the SE-Linux > >> column only going to be created by the --enable-selinux build? If so, > >> that is going to mean that the /data directory is going to be affected > >> by the --enable-selinux flag, which is not ideal --- it would be good if > >> someone could switch to an SE-Linux binary without to dump/reload. One > >> nice idea would be to have one "security" column and allow both > >> SQL-level and SE-Linux security values to be stored in the column, > >> perhaps at the same time; that way there is no new column needed for > >> SE-Linux. > >> > >> I know I suggested the security column act like the system oid column, > >> but now I am thinking I was wrong. The system oid column stores an > >> auto-generated value so it was necessary to have it be specified at > >> CREATE TABLE time because it is guaranteed to take storage space. For > >> the security column, in most cases it will be null, meaning it would not > >> take any storage space becuase we use a null bitmap for null column > >> values. So, perhaps the security column should be in every table and we > >> can just make it default to null; I think that would give us much more > >> flexibility to add security to existing tables. > > > > Sorry, I am confusing system columns, like pg_class.relname, with > > user-table system columns, like mytable.xmin. I don't think we have the > > ability of having user-table system columns nullable, right? > > Currently, it assumes system columns should not be NULL. > heap_getsysattr() always set the given 'isnull' 'false'.
Yep, that is a problem. > > We do have a per-row HEAP_HASOID bit, so I wonder if we can have a > > HEAP_HASSEC bit too. Right now the HEAP_HASOID is controlled by the > > CREATE/ALTER table; > > The current patch add HEAP_HASSECURITY bit to t_infomask. :-) > When it is false, its security field is not available and not allocated. Good. > > I am unclear how hard it would be to allow it to be > > controlled via INSERT, meaning it would be present only if the row had a > > SEC value supplied. > > It is impossible, and not suitable for SE-PostgreSQL. > The HeapTuple is allocated prior to fetch INSERT'ed value. > In addition, SE-PostgreSQL assigns its default security context when no > security attribute is given. When SE-Linux is enabled, couldn't NULL represent the default security context? > > Here is our OID column on some rows but not others: > > > > test=> CREATE TABLE test (x INT) WITH oids; > > CREATE TABLE > > test=> INSERT INTO test VALUES (1); > > INSERT 16392 1 > > test=> ALTER TABLE test SET WITHOUT OIDS; > > ALTER TABLE > > test=> INSERT INTO test VALUES(2); > > INSERT 0 1 > > test=> SELECT oid, * FROM test; > > ERROR: COLUMN "oid" does not exist > > LINE 1: SELECT oid, * FROM test; > > > > but it has per-table granularity; the oid value for '1' is still > > stored, but is no longer visible; that would not work for the security > > value. > > If we can control the Row-level ACLs via table options, what should be > happen when we turn off the feature? > IMO, it is natural to ignore Row-level ACLs independent from whether > the stored tuple actually has ACLs, or not. Hmmm, sounds like perhaps a GUC is needed there. > > The complexity is that the column would always exist (unlike OID), but > > would be NULL if not assigned to. This would allow any table to have > > security by default, and have no overhead if security is not defined for > > the row. Now, I realize SE-Linux would have security defined for each > > row, but SQL-level row security might not, and this would allow the > > feature to be very useful, perhaps with a GUC that required security for > > SE-Linux, and /data would be the same for SE-Linux and non-SE-Linux. If > > we could make the row behave like this we might use separate columns for > > SQL-level and SE-Linux security because there would be no storage > > overhead unless security was used. > > I basically agree for the idea of separate columns. > My preference is "acl column" as general column (not a system column) > which is defined at limited number of tables with ROW_LEVEL_ACL=ON. That would certainly be the easiest approach. -- 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
