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

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: (view raw, whole thread or download thread mbox)
Lists: pgsql-committerspgsql-hackers

* 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.



In response to

pgsql-hackers by date

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

pgsql-committers by date

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

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