Re: [COMMITTERS] pgsql: Add a hook in ExecCheckRTPerms().

From: Stephen Frost <sfrost(at)snowman(dot)net>
To: Simon Riggs <simon(at)2ndQuadrant(dot)com>
Cc: Robert Haas <robertmhaas(at)gmail(dot)com>, Robert Haas <rhaas(at)postgresql(dot)org>, pgsql-hackers(at)postgresql(dot)org
Subject: Re: [COMMITTERS] pgsql: Add a hook in ExecCheckRTPerms().
Date: 2010-07-09 17:19:31
Message-ID: 20100709171931.GV21875@tamriel.snowman.net
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-committers pgsql-hackers

Simon,

* Simon Riggs (simon(at)2ndQuadrant(dot)com) wrote:
> With respect, there doesn't seem to be much use case anyway. I'm sorry
> to be expressing that opinion now; been away for a while. I am somewhat
> amazed that Tom isn't dancing on your head for proposing it though.

I believe it's because we've been through it with him already and
explained how and why it's useful.

> > Well, KaiGai Kohei already posted a proof-of-concept patch showing how
> > this could be used by a simple SE-PostgreSQL implementation. Since we
> > don't have a security labelling facility yet, he used the comment on
> > the relation to store the security label (there are other ways it
> > could be done too, of course).
>
> What's the difference between that and a GRANT command? GRANT is
> designed to allow privileges to be defined at table level. I don't see
> how a plugin whose only API input is a rangetable and which executes
> before any tuples have been touched can possibly add value here.

The *hook*'s API is just a range-table- the plugin has access to a huge
amount of additional information. I don't think it makes sense to try
to limit that in some fashion by dictating what other information the
hook is allowed to gather. Even if we did, it wouldn't be everything
the hook needs since we're not going to collect the SE-Linux label from
the kernel in the main backend code.

The difference between this and a GRANT command would be the whole DAC
vs MAC discussion and overall label-based security (this is *not* the
same as *row-level* security).

> KaiGai's had an uphill task here and I don't wish to be part of slowing
> him down. I'm not seeing how this moves label security forwards in any
> measurable way.

I'm afraid we're talking about different things here.

> Tom's test of a useful plugin has been one where a useful contrib module
> gets added at the same time. I don't think a useful plugin has been
> demonstrated or produced, as yet.

We have a plugin which *could* be used to allow SE-Linux in the backend
today- but it uses the COMMENT system, which isn't exactly ideal.

Robert's already working on a patch which will add the ability to track
actual labels in the catalog (using some new catalog tables which are
similar to the comment tables, which is why it's not done yet, it's
waiting on the get_xxx_oid() infrastructure which will greatly simplify
both), which could then be queried by the module. There will be a hook
there as well, which will get called whenever someone tries to modify or
add a label to an object. We've also discussed new syntax for
supporting those catalogs (ALTER SECURITY LABEL ON TABLE x TO y, or
something like that, it's in the archives).

So, no, it's not done today, but I'm certainly hopeful this will all get
into 9.1 and will allow label-based security for DML with SELinux (and
maybe Smack too) and this is a necessary step along the way.

Thanks,

Stephen

In response to

Browse pgsql-committers by date

  From Date Subject
Next Message Tom Lane 2010-07-09 17:21:54 Re: [COMMITTERS] pgsql: Add a hook in ExecCheckRTPerms().
Previous Message Simon Riggs 2010-07-09 17:12:12 Re: [COMMITTERS] pgsql: Add a hook in ExecCheckRTPerms().

Browse pgsql-hackers by date

  From Date Subject
Next Message Tom Lane 2010-07-09 17:21:54 Re: [COMMITTERS] pgsql: Add a hook in ExecCheckRTPerms().
Previous Message Simon Riggs 2010-07-09 17:18:01 Re: ALTER TABLE SET STATISTICS requires AccessExclusiveLock