Re: [HACKERS] Request: pg_cancel_backend variant that handles 'idle in transaction' sessions

[Joe Conway]

On 11/05/2015 10:48 AM, Pavel Stehule wrote:
> S
> tC
> a<>E
> rA  B A  B  A   n
> t d
> |====---|
> 
> Currently we can set timeout and cancel for period B (). I can see
> based on this discussion that there are legitimate use cases for wanting
> timeout and cancel for any of the periods A, B, or C.
> 
> I guess the question then becomes how we provide that coverage. I think
> for coverage of timeout you need three individual timeout settings.
> However for cancel, it would seem that pg_cancel_transaction would cover
> all three cases.
> 
> 
> It can be difficult to set it properly, because you don't know how much
> statements (cycles of A.B) will be in transaction. Respective for
> setting C, I have to know the number of A,B and it isn't possible everytime.

But you might have a limit you want to enforce regardless of the size or
quantity of A & B periods. That's why it needs to be a separate timeout
IMHO. Let's say I never want a transaction to be around more than 60
minutes no matter what. But I also don't want idle in transaction to
ever exceed 30 seconds, and I don't expect individual statements to
exceed 10 minutes.

Joe

-- 
Crunchy Data - http://crunchydata.com
PostgreSQL Support for Secure Enterprises
Consulting, Training, & Open Source Development



signature.asc
Description: OpenPGP digital signature

Re: [HACKERS] [patch] Proposal for \rotate in psql

[Joe Conway]

On 11/05/2015 12:56 PM, Pavel Stehule wrote:
> 2015-11-05 17:17 GMT+01:00 Joe Conway wrote:
> Hey, I resemble that remark ;-)
> 
> I am sorry, Joe - no any personal attack - I'll pay a beer for you if
> you visit Prague :)

No offense taken, but I might take you up on that beer someday ;-)

-- 
Crunchy Data - http://crunchydata.com
PostgreSQL Support for Secure Enterprises
Consulting, Training, & Open Source Development



signature.asc
Description: OpenPGP digital signature

Re: [HACKERS] Request: pg_cancel_backend variant that handles 'idle in transaction' sessions

[Joe Conway]

On 11/04/2015 01:24 PM, Alvaro Herrera wrote:
> I agree with Pavel.  Having a transaction timeout just does not make any
> sense.  I can see absolutely no use for it.  An idle-in-transaction
> timeout, on the other hand, is very useful.

+1 -- agreed

Joe

-- 
Crunchy Data - http://crunchydata.com
PostgreSQL Support for Secure Enterprises
Consulting, Training, & Open Source Development



signature.asc
Description: OpenPGP digital signature

Re: [HACKERS] Request: pg_cancel_backend variant that handles 'idle in transaction' sessions

[Joe Conway]

On 11/04/2015 02:07 PM, Joshua D. Drake wrote:
> On 11/04/2015 01:55 PM, Stephen Frost wrote:
>> * Joe Conway (m...@joeconway.com) wrote:
>>> On 11/04/2015 01:24 PM, Alvaro Herrera wrote:
>>>> I agree with Pavel.  Having a transaction timeout just does not make
>>>> any
>>>> sense.  I can see absolutely no use for it.  An idle-in-transaction
>>>> timeout, on the other hand, is very useful.
>>>
>>> +1 -- agreed
>>
>> I'm not sure of that.  I can certainly see a use for transaction
>> timeouts- after all, they hold locks and can be very disruptive in the
>> long run.  Further, there are cases where a transaction is normally very
>> fast and in a corner case it becomes extremely slow and disruptive to
>> the rest of the system.  In those cases, having a timeout for it is
>> valuable.
> 
> Yeah but anything holding a lock that long can be terminated via
> statement_timeout can it not?

That is exactly what I was thinking


-- 
Crunchy Data - http://crunchydata.com
PostgreSQL Support for Secure Enterprises
Consulting, Training, & Open Source Development



signature.asc
Description: OpenPGP digital signature

Re: [HACKERS] [patch] Proposal for \rotate in psql

[Joe Conway]

On 11/04/2015 04:09 AM, Pavel Stehule wrote:
> I am looking on this last patch. I talked about the name of this command
> with more people, and the name "rotate" is unhappy. The correct name for
> this visualization technique is "crosstab" (see google "crosstab"). The
> conflict with our extension is unhappy, but using "rotate" is more worst
> - (see google "rotate"). The term "rotate" is used less time (related to
> topic), and usually with zero informed people. More, in attached doc,
> the word "crosstab" is pretty often used, and then the word "rotate" has
> not sense.

Apologies if this has already been suggested (as I have not followed the
entire thread), but if you don't want to conflict with the name
crosstab, perhaps "pivot" would be better?

Joe

-- 
Crunchy Data - http://crunchydata.com
PostgreSQL Support for Secure Enterprises
Consulting, Training, & Open Source Development



signature.asc
Description: OpenPGP digital signature

Re: [HACKERS] ALTER SYSTEM vs symlink

[Joe Conway]

On 11/02/2015 09:24 AM, Stephen Frost wrote:
> I certainly look forward to having more fine grained control, to the
> point where I'd like to be able to run a system reasonably without an
> active superuser login.  Having superusers logging into production
> running databases is extremely dangerous.  What I have seen happening,
> in multiple organizations, is a move to proxy everything going to the
> database through some other system which attempts to vet and verify that
> the action is acceptable (this also happens to offer up much better
> auditing than what we have today).

I've seen this *repeatedly* in the past few years as well.

> I feel confident that we can provide a better solution than those proxy-based 
> approaches.

+1

Joe

-- 
Crunchy Data - http://crunchydata.com
PostgreSQL Support for Secure Enterprises
Consulting, Training, & Open Source Development



signature.asc
Description: OpenPGP digital signature

Re: [HACKERS] exposing pg_controldata and pg_config as functions

[Joe Conway]

On 10/30/2015 06:53 AM, Erik Rijkers wrote:
>> [2015082503-pgconfig_controldata.diff]
> 
> I tried to build this, and the patch applies cleanly but then a ld error
> emerges:

I'm sure the patch would need to be rebased, but the last thread died
with significant complaints and questions about what was the correct
approach. I therefore never even bothered submitting my latest patch
version. I'll try to pick this back up in the next week and see if I can
come up with something we can get a consensus on...

Joe

-- 
Crunchy Data - http://crunchydata.com
PostgreSQL Support for Secure Enterprises
Consulting, Training, & Open Source Development



signature.asc
Description: OpenPGP digital signature

Re: [HACKERS] ALTER SYSTEM vs symlink

[Joe Conway]

On 11/02/2015 08:33 AM, Stephen Frost wrote:
> A deeper hook in the ALTER SYSTEM might be another approach, or one
> in the GUC system to allow external libraries to control what various
> GUCs can be set to (either via ALTER SYSTEM or through regular SET
> calls).


I have run into multiple situations where having finer grained control
over the setting of GUCs would have been very useful, and spoken to many
others in the community with the same wish.


> I'd like the ability to control all of the above, ultimately.  I
> don't believe that we should be allowing the superuser to always
> modify the catalog directly

+10

Joe

-- 
Crunchy Data - http://crunchydata.com
PostgreSQL Support for Secure Enterprises
Consulting, Training, & Open Source Development



signature.asc
Description: OpenPGP digital signature

[HACKERS] Re: [BUGS] BUG #13694: Row Level Security by-passed with CREATEUSER permission

[Joe Conway]

On 10/21/2015 12:46 PM, Tom Lane wrote:
> Attached patch rips out CREATEUSER and NOCREATEUSER options lock, stock,
> and barrel.

Looks good to me.

> Another possibility is to change them to actually mean CREATEROLE and
> NOCREATEROLE.  I think probably a clean break is better though.


I think that would be too confusing. I'd rather see them go away ala
your patch.

Joe

-- 
Crunchy Data - http://crunchydata.com
PostgreSQL Support for Secure Enterprises
Consulting, Training, & Open Source Development



signature.asc
Description: OpenPGP digital signature

Re: [HACKERS] dblink: add polymorphic functions.

[Joe Conway]

On 07/30/2015 09:51 AM, Tom Lane wrote:
> Joe Conway <m...@joeconway.com> writes:
>> What about just TYPE then?
> 
>> SELECT x::TYPE(some_expression) FROM ...
>> SELECT CAST (x AS TYPE(some_expression)) FROM ...

> The main limitation of this patch is that it won't work for call sites
> that pass pstate == NULL to LookupTypeName.  There are a fair number
> of them, some of which wouldn't care because they could never invoke
> this notation anyway, but for others we'd need to do some work to cons
> up a suitable pstate.

Sorry it took so long for me to get back to this, but any reason the
attached won't work?

Joe

-- 
Crunchy Data - http://crunchydata.com
PostgreSQL Support for Secure Enterprises
Consulting, Training, & Open Source Development
diff --git a/src/backend/parser/parse_agg.c b/src/backend/parser/parse_agg.c
index 5b0d568..a1aba26 100644
*** a/src/backend/parser/parse_agg.c
--- b/src/backend/parser/parse_agg.c
*** check_agglevels_and_constraints(ParseSta
*** 485,490 
--- 485,493 
  err = _("grouping operations are not allowed in trigger WHEN conditions");
  
  			break;
+ 		case EXPR_KIND_TYPE:
+ 			/* okay */
+ 			break;
  
  			/*
  			 * There is intentionally no default: case here, so that the
*** transformWindowFuncCall(ParseState *psta
*** 842,847 
--- 845,853 
  		case EXPR_KIND_TRIGGER_WHEN:
  			err = _("window functions are not allowed in trigger WHEN conditions");
  			break;
+ 		case EXPR_KIND_TYPE:
+ 			/* okay */
+ 			break;
  
  			/*
  			 * There is intentionally no default: case here, so that the
diff --git a/src/backend/parser/parse_expr.c b/src/backend/parser/parse_expr.c
index fa77ef1..9f76ee6 100644
*** a/src/backend/parser/parse_expr.c
--- b/src/backend/parser/parse_expr.c
*** transformSubLink(ParseState *pstate, Sub
*** 1690,1695 
--- 1690,1696 
  		case EXPR_KIND_OFFSET:
  		case EXPR_KIND_RETURNING:
  		case EXPR_KIND_VALUES:
+ 		case EXPR_KIND_TYPE:
  			/* okay */
  			break;
  		case EXPR_KIND_CHECK_CONSTRAINT:
*** ParseExprKindName(ParseExprKind exprKind
*** 3225,3230 
--- 3226,3233 
  			return "EXECUTE";
  		case EXPR_KIND_TRIGGER_WHEN:
  			return "WHEN";
+ 		case EXPR_KIND_TYPE:
+ 			return "TYPE";
  
  			/*
  			 * There is intentionally no default: case here, so that the
diff --git a/src/backend/parser/parse_type.c b/src/backend/parser/parse_type.c
index 6616639..19a2684 100644
*** a/src/backend/parser/parse_type.c
--- b/src/backend/parser/parse_type.c
***
*** 19,25 
--- 19,27 
  #include "catalog/pg_type.h"
  #include "lib/stringinfo.h"
  #include "nodes/makefuncs.h"
+ #include "nodes/nodeFuncs.h"
  #include "parser/parser.h"
+ #include "parser/parse_expr.h"
  #include "parser/parse_type.h"
  #include "utils/array.h"
  #include "utils/builtins.h"
*** static int32 typenameTypeMod(ParseState
*** 52,58 
   * found but is a shell, and there is typmod decoration, an error will be
   * thrown --- this is intentional.
   *
!  * pstate is only used for error location info, and may be NULL.
   */
  Type
  LookupTypeName(ParseState *pstate, const TypeName *typeName,
--- 54,60 
   * found but is a shell, and there is typmod decoration, an error will be
   * thrown --- this is intentional.
   *
!  * In most cases pstate is only used for error location info, and may be NULL.
   */
  Type
  LookupTypeName(ParseState *pstate, const TypeName *typeName,
*** LookupTypeName(ParseState *pstate, const
*** 60,66 
  {
  	Oid			typoid;
  	HeapTuple	tup;
! 	int32		typmod;
  
  	if (typeName->names == NIL)
  	{
--- 62,68 
  {
  	Oid			typoid;
  	HeapTuple	tup;
! 	int32		typmod = -2;
  
  	if (typeName->names == NIL)
  	{
*** LookupTypeName(ParseState *pstate, const
*** 143,148 
--- 145,172 
  			format_type_be(typoid;
  		}
  	}
+ 	else if (list_length(typeName->typmods) == 1 &&
+ 			 list_length(typeName->names) == 1 &&
+ 			 strcmp(strVal(linitial(typeName->names)), "type") == 0)
+ 	{
+ 		/* TYPE(expression) notation */
+ 		Node	   *typexpr = (Node *) linitial(typeName->typmods);
+ 
+ 		/* If needed, create a dummy ParseState for transformExpr */
+ 		if (pstate == NULL)
+ 			pstate = make_parsestate(NULL);
+ 
+ 		typexpr = transformExpr(pstate, typexpr, EXPR_KIND_TYPE);
+ 
+ 		/* We needn't bother assigning collations to the expr */
+ 		/* We use the expression's type/typmod and then throw the expr away */
+ 		typoid = exprType(typexpr);
+ 		typmod = exprTypmod(typexpr);
+ 
+ 		/* If an array reference, return the array type instead */
+ 		if (typeName->arrayBounds != NIL)
+ 			typoid = get_array_type(typoid);
+ 	}
  	else
  	{
  		/* Normal reference to a type name */

[HACKERS] Proposal: SET ROLE hook

[Joe Conway]

In many environments there is a policy requiring users to login using
unprivileged accounts, and then escalate their privileges if and when
they require it. In PostgreSQL this could be done by granting the
superuser role to an unprivileged user with noinherit, and then making
the superuser role nologin. Something like:

8<-
psql -U postgres
create user joe noinherit;
grant postgres to joe;
alter user postgres nologin;
\q
psql -U joe
-- do stuff *not requiring* escalated privs
set role postgres;
-- do stuff *requiring* escalated privs
reset role;
8<-

One of the problems with this is we would ideally like to know whenever
joe escalates himself to postgres. Right now that is not really possible
without doing untenable things such as logging every statement.

In order to address this issue, I am proposing a new SET ROLE hook. The
attached patch (role-esc-hook.diff) is I believe all we need. Then
extension authors could implement logging of privilege escalation.

A proof of concept extension patch is also attached. That one is not
meant to be applied, just illustrates one potential use of the hook. I
just smashed it on top of passwordcheck for the sake of convenience.

With both patches applied, the following scenario:
8<
psql -U joe postgres
psql (9.6devel)
Type "help" for help.

postgres=> set role postgres;
SET
postgres=# select rolname, rolpassword from pg_authid;
 rolname  | rolpassword
--+-
 joe  |
 postgres |
(2 rows)

postgres=# set log_statement = none;
SET
postgres=# reset role;
RESET
8<

Generates the following in the log:

8<
LOG:  Role joe transitioning to Superuser Role postgres
STATEMENT:  set role postgres;
LOG:  statement: select rolname, rolpassword from pg_authid;
LOG:  statement: set log_statement = none;
LOG:  Superuser Role postgres transitioning to Role joe
STATEMENT:  reset role;
8<

Note that we cannot prevent joe from executing
  set log_statement = none;
but we at least get the evidence in the log and can ask joe why he felt
the need to do that. We could also set up alerts based on the logged
events, etc.

This particular hook will not capture role changes due to SECURITY
DEFINER functions, but I think that is not only ok but preferred.
Escalation during a SECURITY DEFINER function is a preplanned sanctioned
event, unlike an ad hoc unconstrained role change to superuser. And
given the demo patch, we could see any SECURITY DEFINER function created
by the superuser when it gets created in the log (which again is subject
to auditing, alerts, etc.)

Ultimately I would also like to see a general hook available which would
fire for all changes to GUC settings, but I think this one is still very
useful as it is highly targeted.

Comments?

Thanks,

Joe

-- 
Crunchy Data - http://crunchydata.com
PostgreSQL Support for Secure Enterprises
Consulting, Training, & Open Source Development

diff --git a/src/backend/commands/variable.c b/src/backend/commands/variable.c
index 2d0a44e..76b3957 100644
*** a/src/backend/commands/variable.c
--- b/src/backend/commands/variable.c
***
*** 31,36 
--- 31,38 
  #include "utils/timestamp.h"
  #include "mb/pg_wchar.h"
  
+ SetRole_hook_type SetRole_hook = NULL;
+ 
  /*
   * DATESTYLE
   */
*** assign_role(const char *newval, void *ex
*** 904,909 
--- 906,919 
  {
  	role_auth_extra *myextra = (role_auth_extra *) extra;
  
+ 	/*
+ 	 * Any defined hooks must be able to execute in a failed
+ 	 * transaction to restore a prior value of the ROLE GUC variable.
+ 	 */
+ 	if (SetRole_hook)
+ 		(*SetRole_hook) (GetUserId(),
+ 		 myextra->roleid, myextra->is_superuser);
+ 
  	SetCurrentRoleId(myextra->roleid, myextra->is_superuser);
  }
  
diff --git a/src/include/commands/variable.h b/src/include/commands/variable.h
index 9cf2edd..be243df 100644
*** a/src/include/commands/variable.h
--- b/src/include/commands/variable.h
***
*** 12,17 
--- 12,20 
  
  #include "utils/guc.h"
  
+ /* Hook for plugins to get control in check_role() */
+ typedef void (*SetRole_hook_type) (Oid, Oid, bool);
+ extern PGDLLIMPORT SetRole_hook_type SetRole_hook;
  
  extern bool check_datestyle(char **newval, void **extra, GucSource source);
  extern void assign_datestyle(const char *newval, void *extra);
diff --git a/contrib/passwordcheck/passwordcheck.c b/contrib/passwordcheck/passwordcheck.c
index 78c44b2..867a703 100644
*** a/contrib/passwordcheck/passwordcheck.c
--- b/contrib/passwordcheck/passwordcheck.c
***
*** 21,28 
--- 21,31 
  #endif
  
  #include "commands/user.h"
+ #include "commands/variable.h"
  #include "fmgr.h"
+ #include "miscadmin.h"
  #include "libpq/md5.h"
+ #include "utils/memutils.h"
  
  PG_MODULE_MAGIC;
  
*** PG_MODULE_MAGIC;
*** 31,36 
--- 34,41 
  
  extern void _PG_init(void);
  
+ char	   *save_log_statement = NULL;
+ 
  

Re: [HACKERS] Proposal: SET ROLE hook

[Joe Conway]

On 10/16/2015 09:28 AM, Andres Freund wrote:
> Alternatively you can just have a elevate_user() function that does the
> logging and escalating? That seems like the same amount of code and it'd
> work with released versions of postgres?
> 
> Sure, that has some disadvantages over your approach, but for the
> presented use case with humans needing to escalate I don't see any.

Hmmm, do you mean essentially skip the "GRANT postgres to joe" and use a
SECURITY DEFINER C function that does the set role to postgres under the
covers with "GRANT EXECUTE on FUNCTION elevate_user() to joe"? Being
able to use something like that on existing versions would be very nice,
but it feels kind of grotty. Or maybe you mean something else?

Joe

-- 
Crunchy Data - http://crunchydata.com
PostgreSQL Support for Secure Enterprises
Consulting, Training, & Open Source Development



signature.asc
Description: OpenPGP digital signature

Re: [HACKERS] Multi-tenancy with RLS

[Joe Conway]

On 10/08/2015 11:04 PM, Stephen Frost wrote:
> * Robert Haas (robertmh...@gmail.com) wrote:
>> We've got one reloption for views already - security_barrier.  Maybe
>> we could have another one that effectively changes a particular view
>> from "security definer" as it is today to "security invoker".
> 
> As I recall, there was a previous suggestion (honestly, I thought it was
> your idea) to have a reloption which made views "fully" security
> definer, in that functions in the view definition would run as the view
> owner instead of the view invoker.

I'd love to see a way for views to behave in an entirely view definer or
entirely view invoker way. The current mixed mode is bad/confusing IMHO,
although I guess we need some backward compatibility mode?

> I liked that idea, though we would need to have a function to say "who
> is the 'outer' user?" (CURRENT_USER always being the owner with the
> above described reloption).
> 
> I'm less sure about the idea of having a view which runs entirely as the
> view invoker, but I'm not against it either.
> 
> I do think both of those are independent of supporting policies for
> views and foreign tables though, which we'd want even if we had
> reloptions for the above ideas.

Agreed

Joe

-- 
Crunchy Data - http://crunchydata.com
PostgreSQL Support for Secure Enterprises
Consulting, Training, & Open Source Development



signature.asc
Description: OpenPGP digital signature

Re: [HACKERS] Use EVP API pgcrypto encryption, dropping support for OpenSSL 0.9.6 and older

[Joe Conway]

On 10/05/2015 06:02 AM, Heikki Linnakangas wrote:
> There was prior discussion on the EVP API in this old thread from 2007:
> http://www.postgresql.org/message-id/flat/46a5e284.7030...@sun.com#46a5e284.7030...@sun.com
> 
> 
> In short, pgcrypto actually used to use the EVP functions, but was
> changed to *not* use them, because in older versions of OpenSSL, some
> key lengths and/or padding options that pgcrypto supports were not
> supported by the EVP API. That was fixed in OpenSSL 0.9.7, however. The
> consensus in 2007 was that we could drop support for OpenSSL 0.9.6 and
> below, so that should definitely be OK by now, if we haven't already
> done that elsewhere in the code.
> 
> Any objections to the attached two patches?

I haven't studied that patches themselves yet, but +1 for the concept.

Joe

-- 
Crunchy Data - http://crunchydata.com
PostgreSQL Support for Secure Enterprises
Consulting, Training, & Open Source Development



signature.asc
Description: OpenPGP digital signature

[HACKERS] SESSION SESSION - bug or intentional?

[Joe Conway]

I was looking at something in gram.y when I noticed that the following
production works:


SET SESSION SESSION CHARACTERISTICS AS TRANSACTION READ ONLY;


"SESSION SESSION" seems fairly odd -- is it intentional?

Joe

-- 
Crunchy Data - http://crunchydata.com
PostgreSQL Support for Secure Enterprises
Consulting, Training, & Open Source Development



signature.asc
Description: OpenPGP digital signature

Re: [HACKERS] Idea for improving buildfarm robustness

[Joe Conway]

On 09/29/2015 01:48 PM, Alvaro Herrera wrote:
> Joe Conway wrote:
>> On 09/29/2015 12:47 PM, Tom Lane wrote:
>>> We could possibly add additional checks, like trying to verify that
>>> pg_control has the same inode number it used to.  But I'm afraid that
>>> would add portability issues and false-positive hazards that would
>>> outweigh the value.
>>
>> Not sure you remember the incident, but I think years ago that would
>> have saved me some heartache ;-)
> 
> I remember it, but I'm not sure it would have helped you.  As I recall,
> your trouble was that after a reboot the init script decided to initdb
> the mount point -- postmaster wouldn't have been running at all ...

Right, which the init script non longer does as far as I'm aware, so
hopefully will never happen again to anyone.

But it was still a case where the postmaster started on one copy of
PGDATA (the newly init'd copy), and then the contents of the real PGDATA
was swapped in (when the filesystem was finally mounted), causing
corruption to the production data.

Joe

-- 
Crunchy Data - http://crunchydata.com
PostgreSQL Support for Secure Enterprises
Consulting, Training, & Open Source Development



signature.asc
Description: OpenPGP digital signature

Re: [HACKERS] Idea for improving buildfarm robustness

[Joe Conway]

On 09/29/2015 12:47 PM, Tom Lane wrote:
> We could possibly add additional checks, like trying to verify that
> pg_control has the same inode number it used to.  But I'm afraid that
> would add portability issues and false-positive hazards that would
> outweigh the value.

Not sure you remember the incident, but I think years ago that would
have saved me some heartache ;-)

Joe

-- 
Crunchy Data - http://crunchydata.com
PostgreSQL Support for Secure Enterprises
Consulting, Training, & Open Source Development



signature.asc
Description: OpenPGP digital signature

Re: [HACKERS] No Issue Tracker - Say it Ain't So!

[Joe Conway]

On 09/25/2015 09:32 AM, Tom Lane wrote:
> 2. There's no visibility for outsiders as to what issues are open or
> recently fixed.  Not being outsiders, I'm not sure that we are terribly
> well qualified to describe this problem precisely or identify a good
> solution --- but I grant that there's a problem there.
> 
> I do not know how much emphasis the project should place on point #2.
> By definition, fixing that will not return any direct benefit to us.

I would argue that there is some benefit for us in terms of advocacy. We
certainly get criticized for our lack of a bug tracker. I don't know of
anyone who specifically rejected Postgres because of that fact, but
would not be surprised if has happened.

Joe

-- 
Crunchy Data - http://crunchydata.com
PostgreSQL Support for Secure Enterprises
Consulting, Training, & Open Source Development



signature.asc
Description: OpenPGP digital signature

Re: [HACKERS] No Issue Tracker - Say it Ain't So!

[Joe Conway]

On 09/24/2015 10:08 AM, Stephen Frost wrote:
> debbugs does most of the above by default, no programming needed...  I'm
> sure we could get it to integrate with the commitfest and have a git
> commit hook which sends the appropriate email to it also.
> 
> That the emacs folks are using it makes me *much* more interested in the
> idea of getting debbugs up and running..

I'm not familiar with debbugs myself, but given that description it
sounds to me like it would be worth giving it a try.

Joe

-- 
Crunchy Data - http://crunchydata.com
PostgreSQL Support for Secure Enterprises
Consulting, Training, & Open Source Development



signature.asc
Description: OpenPGP digital signature

Re: [HACKERS] No Issue Tracker - Say it Ain't So!

[Joe Conway]

On 09/23/2015 05:21 PM, Thomas Munro wrote:
> Do you think it would make any sense to consider evolving what we have
> already?  At the moment, we have a bug form, and when you submit it it
> does this (if I'm looking at the right thing, please correct me if I'm
> not):
> 
> http://git.postgresql.org/gitweb/?p=pgweb.git;a=blob;f=pgweb/misc/views.py
> 
> That is, the database interaction is limited to using a SEQUENCE to
> generate a new bug ID, and then an email is sent to pgsql-bugs.  What
> if we also created a bug record for that ID to track its status, and
> allowed anyone with a community account to edit the bug record and
> change the status?  There could be a simple page that lets you see and
> search for bugs, with a link to the flat mail archive thread where
> discussion is held.  All actual discussion would continue on mailing
> lists.  That would be similar to the commitfest.
> 
> I suppose some forms of cross-reference would also be useful: when
> viewing the bug's page, you might want to see any commitfest items or
> pgsql-committers messages that relate to that bug.  Perhaps we could
> automatically create those links when bug IDs are recognised in those
> messages, so that no extra workflow/maintenance is required in


It would be nice if you could essentially promote a bug into a
commitfest item, maybe through a status change.


> straightforward cases.  To continue that line of thinking it would
> also be possible for bug statuses to be changed when certain words are
> spotted in either commit messages (which doesn't have to be a commit
> hook, it could be taken from pgsql-committers messages) or pgsql-bugs
> messages.
> 
> Cf github commit message parsing:
> https://help.github.com/articles/closing-issues-via-commit-messages/

I was thinking along the same lines. If we could paste a bug reference
number into the commit message and have that change the bug status it
would go a long way to making this workable I think.

Joe

-- 
Crunchy Data - http://crunchydata.com
PostgreSQL Support for Secure Enterprises
Consulting, Training, & Open Source Development



signature.asc
Description: OpenPGP digital signature

Re: [HACKERS] One question about security label command

[Joe Conway]

On 09/15/2015 11:36 AM, Joe Conway wrote:
> On 09/13/2015 10:29 AM, Kouhei Kaigai wrote:
>> The attached one is the regression test fixup in v9.2.
>> As we applied to the v9.3 or later, it replaces unconfined_t domain
>> by the self defined sepgsql_regtest_superuser_t.

> Thanks -- I'll look through this over the next day or two.

Took a bit longer than I thought but now pushed :-)

At this point all current branches should be passing the sepgsql
regression test. As a reminder, that would be:

  rhino: 9.2 through master
  agama: 9.1

Joe

-- 
Crunchy Data - http://crunchydata.com
PostgreSQL Support for Secure Enterprises
Consulting, Training, & Open Source Development



signature.asc
Description: OpenPGP digital signature

Re: [HACKERS] row_security GUC, BYPASSRLS

[Joe Conway]

On 09/18/2015 09:25 AM, Adam Brightwell wrote:
>>> 1. remove row_security=force
>>> 2. remove SECURITY_ROW_LEVEL_DISABLED; make ri_triggers.c subject to 
>>> policies
>>> 3. add DDL-controlled, per-table policy forcing
>>>
>>> They ought to land in that order.  PostgreSQL 9.5 would need at least (1) 
>>> and
>>> (2); would RLS experts find it beneficial for me to take care of those?
>>
>> That would be awesome, but I would say that if we do #1 & 2 for 9.5, we
>> also need #3.
> 
> Agreed.  Please let me know if there is anything I can do to help.


Yes, same here.

Joe


-- 
Crunchy Data - http://crunchydata.com
PostgreSQL Support for Secure Enterprises
Consulting, Training, & Open Source Development



signature.asc
Description: OpenPGP digital signature

Re: [HACKERS] row_security GUC, BYPASSRLS

[Joe Conway]

On 09/18/2015 01:07 AM, Noah Misch wrote:
> Great.  Robert, does that work for you, too?  If so, this sub-thread is
> looking at three patches:
> 
> 1. remove row_security=force
> 2. remove SECURITY_ROW_LEVEL_DISABLED; make ri_triggers.c subject to policies
> 3. add DDL-controlled, per-table policy forcing
> 
> They ought to land in that order.  PostgreSQL 9.5 would need at least (1) and
> (2); would RLS experts find it beneficial for me to take care of those?

That would be awesome, but I would say that if we do #1 & 2 for 9.5, we
also need #3.

Joe


-- 
Crunchy Data - http://crunchydata.com
PostgreSQL Support for Secure Enterprises
Consulting, Training, & Open Source Development



signature.asc
Description: OpenPGP digital signature

Re: [HACKERS] One question about security label command

[Joe Conway]

On 09/13/2015 10:29 AM, Kouhei Kaigai wrote:
> The attached one is the regression test fixup in v9.2.
> As we applied to the v9.3 or later, it replaces unconfined_t domain
> by the self defined sepgsql_regtest_superuser_t.
> 
> Unfortunately, I found a bug to process SELECT INTO statement.
> Because v9.2 didn't have ObjectAccessPostCreate to inform the
> context when a relation is newly created, thus, sepgsql had
> an ugly alternative at sepgsql_executor_start().
> It saves kind of statement prior to executor start, then it is
> referenced when sepgsql_relation_post_create() is called.
> However, T_CreateTableAsStmt was oversight, thus it is considered
> as a harmless internal operation, and no label was assigned on
> the new relation.
> I'm not certain why we oversight at that time, however, this logic
> is removed and replaced in v9.3. 

Thanks -- I'll look through this over the next day or two.

Joe

-- 
Crunchy Data - http://crunchydata.com
PostgreSQL Support for Secure Enterprises
Consulting, Training, & Open Source Development



signature.asc
Description: OpenPGP digital signature

Re: [HACKERS] row_security GUC, BYPASSRLS

[Joe Conway]

On 09/15/2015 12:53 PM, Tom Lane wrote:
> Joe Conway <m...@joeconway.com> writes:
>> There are use cases where row_security=force will be set in production
>> environments, not only in testing.
> 
> What cases, exactly, and is there another way to solve those problems?
> I concur with Noah's feeling that allowing security behavior to depend on
> a GUC is risky.

There are environments where there is a strong desire to use RLS to
control access in production, even for table owners and superusers.
Obviously there are more steps needed to completely achieve this level
of control, but removing the ability to force row security is going in
the wrong direction. Noah's suggestion of using a per table attribute
would work -- in fact I like the idea of that better than using the
current GUC.

Joe

-- 
Crunchy Data - http://crunchydata.com
PostgreSQL Support for Secure Enterprises
Consulting, Training, & Open Source Development



signature.asc
Description: OpenPGP digital signature

Re: [HACKERS] row_security GUC, BYPASSRLS

[Joe Conway]

On 09/15/2015 10:58 AM, Robert Haas wrote:
> I can't argue with that, I suppose, but I think row_security=force is
> a pretty useful convenience.  If we must remove it, so be it, but I'd
> be a little sad.

There are use cases where row_security=force will be set in production
environments, not only in testing. I would be very strongly opposed to
removing the ability to force RLS from being applied to owners and
superusers, and in fact think we should figure out how to make changing
row_security, once it is set, more difficult.

Joe

-- 
Crunchy Data - http://crunchydata.com
PostgreSQL Support for Secure Enterprises
Consulting, Training, & Open Source Development



signature.asc
Description: OpenPGP digital signature

Re: [HACKERS] row_security GUC, BYPASSRLS

[Joe Conway]

On 09/15/2015 11:10 AM, Tom Lane wrote:
> Robert Haas  writes:
>> On Tue, Sep 15, 2015 at 1:00 AM, Noah Misch  wrote:
>>> It also requires a DBA unwilling to
>>> furnish test accounts to custodians of sensitive data.  With or without
>>> row_security=force, such a team is on the outer perimeter of the audience 
>>> able
>>> to benefit from RLS.  Nonetheless, I'd welcome a replacement test aid.
> 
>> I can't argue with that, I suppose, but I think row_security=force is
>> a pretty useful convenience.  If we must remove it, so be it, but I'd
>> be a little sad.
> 
> Keep in mind that if you have an uncooperative DBA on your production
> system, you can always test your policy to your heart's content on a
> playpen installation.  In fact, most people would consider that good
> engineering practice anyway, rather than pushing untested code directly
> into production.


That's exactly right. We should provide flexibility for testing in test
environments, and also the ability to lock things down tight in production.

Joe

-- 
Crunchy Data - http://crunchydata.com
PostgreSQL Support for Secure Enterprises
Consulting, Training, & Open Source Development



signature.asc
Description: OpenPGP digital signature

Re: [HACKERS] RLS open items are vague and unactionable

[Joe Conway]

On 09/11/2015 04:33 AM, Stephen Frost wrote:
> * Dean Rasheed (dean.a.rash...@gmail.com) wrote:
>> I will happily work up a rebased version of the patch, but only if I
>> get a serious commitment from a committer to review it. Otherwise,
>> I'll let it drop.
> 
> There's no question about getting it reviewed and moving it forward;
> either Joe or myself will certainly be able to handle that if others
> don't step up. 

Yes, we'll get it done.

-- 
Crunchy Data - http://crunchydata.com
PostgreSQL Support for Secure Enterprises
Consulting, Training, & Open Source Development



signature.asc
Description: OpenPGP digital signature

Re: [HACKERS] Multi-tenancy with RLS

[Joe Conway]

On 09/01/2015 11:25 PM, Haribabu Kommi wrote:
> If any user is granted any permissions on that object then that user
> can view it's meta data of that object from the catalog tables.
> To check the permissions of the user on the object, instead of
> checking each and every available option, I just added a new
> privilege check option called "any". If user have any permissions on
> the object, the corresponding permission check function returns
> true. Patch attached for the same.
> 
> Any thoughts/comments?

Thanks for working on this! Overall I like the concept and know of use
cases where it is critical and should be supported. Some comments:

1.) "... WITH ROW LEVEL SECURITY ...": name is not really accurate. This
feature does not, for example automatically add row security to all
tables in the database. It is really a specific set of RLS policies on
system tables to accomplish one very specific goal -- restrict metadata
access to those objects on which the user has some access. So maybe
something like one of these?
  ... WITH METADATA SECURITY ...
  ... WITH CATALOG SECURITY ...
  ... WITH METADATA RESTRICT ...
  ... WITH CATALOG RESTRICT ...

2.) Related to #1, I wonder if we should even provide a set of policies,
or should we just allow RLS on system tables and let people create their
own policies to suit their own needs. Maybe that could be dangerous, but
so are a lot of things we allow superusers do.

3.) In RelationBuildRowSecurity:

8<--
+   /* */
+   if (!criticalRelcachesBuilt || !criticalSharedRelcachesBuilt ||
relation->rd_id == PolicyRelationId)
+   return;
8<--

Bypassing RelationBuildRowSecurity() for relation->rd_id ==
PolicyRelationId causes a segfault for me and prevents me from even
logging into the database. Additionally I would want row security to
apply to pg_policy as well. Maybe not the best approach, but I solved
the infinite recursion issue like this:

8<--
diff --git a/src/backend/commands/policy.c b/src/backend/commands/policy.c
index 45326a3..49db767 100644
*** a/src/backend/commands/policy.c
--- b/src/backend/commands/policy.c
*** static char parse_policy_command(const c
*** 52,57 
--- 105,116 
  static Datum *policy_role_list_to_array(List *roles, int *num_roles);

  /*
+  * used to prevent infinite recursion when building
+  * row security for pg_policy itself
+  */
+ int rdepth = 0;
+
+ /*
   * Callback to RangeVarGetRelidExtended().
   *
   * Checks the following:
*** RelationBuildRowSecurity(Relation relati
*** 197,202 
--- 257,273 
MemoryContext oldcxt = CurrentMemoryContext;
RowSecurityDesc *volatile rsdesc = NULL;

+   /* */
+   if (!criticalRelcachesBuilt || !criticalSharedRelcachesBuilt)
+   return;
+   if (relation->rd_id == PolicyRelationId && rdepth > 0)
+   {
+   rdepth = 0;
+   return;
+   }
+   if (relation->rd_id == PolicyRelationId)
+   rdepth = 1;
+
/*
 * Create a memory context to hold everything associated with this
 * relation's row security policy.  This makes it easy to clean
up during
*** RelationBuildRowSecurity(Relation relati
*** 366,377 
--- 437,450 
/* Delete rscxt, first making sure it isn't active */
MemoryContextSwitchTo(oldcxt);
MemoryContextDelete(rscxt);
+   rdepth = 0;
PG_RE_THROW();
}
PG_END_TRY();

/* Success --- attach the policy descriptor to the relcache entry */
relation->rd_rsdesc = rsdesc;
+   rdepth = 0;
  }

  /*
8<--

4.) Currently, policies are always installed in the current database
rather than the target database. Didn't try to figure out how to fix:
8<--
postgres=# create database test with ROW LEVEL SECURITY = true;
CREATE DATABASE
postgres=# select count(1) from pg_policy;
 count
---
30
(1 row)

postgres=# \c test
You are now connected to database "test" as user "postgres".
test=# select count(1) from pg_policy;
 count
---
 0
(1 row)
8<--

5.) I'm not thrilled with all the additional included headers added to
policy.c for this, but I don't offhand see a better way either.

6.) I would like to see this work in conjunction with sepgsql (and/or
other security label providers) as well. That could be accomplished
either as mentioned in #2 above (let me create custom policies to suit
my needs), or by providing security label hooks somewhere that they
affect the output of the has__privilege*() functions.

HTH,

Joe

-- 
Crunchy Data - http://crunchydata.com
PostgreSQL Support for Secure Enterprises
Consulting, Training, & Open Source Development



signature.asc
Description: OpenPGP digital signature

Re: [HACKERS] Modernizing contrib/tablefunc

[Joe Conway]

On 09/09/2015 03:03 PM, David Fetter wrote:
> Folks,
> 
> While doing some research for the upcoming (UN)PIVOT proposal, I
> noticed that there were some hairy and no-longer-needed bits in the
> regression tests for tablefunc, which I have shaved off with the
> attached patch.
> 
> What say?

Is the entire patch just eliminating '' by using dollar quoting? I'm not
against the idea, but it hardly seems worth the effort.

Joe

-- 
Crunchy Data - http://crunchydata.com
PostgreSQL Support for Secure Enterprises
Consulting, Training, & Open Source Development



signature.asc
Description: OpenPGP digital signature

Re: [HACKERS] One question about security label command

[Joe Conway]

On 08/30/2015 11:17 AM, Joe Conway wrote:
>>> 3.) Rework patch for 9.2 (Kohei)

>>> 4.) Finish standing up the RHEL/CentOS 7.x buildfarm member to
>>> test sepgsql on 9.2 and up. The animal (rhinoceros) is running
>>> already, but still needs some custom scripting. (Joe, Andrew)

>>> 5.) Additionally stand up a RHEL/CentOS 6.x buildfarm member to
>>> test sepgsql on 9.1 (no changes) (Joe).

> Additionally I have #5 (the 6.x buildfarm member) created/working and
> I sent in my registration form. It has not been accepted yet.

Many thanks to Andrew -- #4 and 5 now complete. Rhinoceros is now
successfully testing sepgsql for 9.2 -> HEAD on CentOS 7.1, and a new
animal, agama, is testing 9.1 on CentOS 6.7.

Remember, expect 9.2 to fail until/unless we get a reworked patch for it.

Joe

-- 
Crunchy Data - http://crunchydata.com
PostgreSQL Support for Secure Enterprises
Consulting, Training, & Open Source Development



signature.asc
Description: OpenPGP digital signature

Re: [HACKERS] One question about security label command

[Joe Conway]

On 09/07/2015 04:46 PM, Kouhei Kaigai wrote:
> 3.) Rework patch for 9.2 (Kohei)
>>
> Could you wait for the next Monday?
> I'll try to work this in the next weekend.

Sure, that would be great.

Joe

-- 
Crunchy Data - http://crunchydata.com
PostgreSQL Support for Secure Enterprises
Consulting, Training, & Open Source Development



signature.asc
Description: OpenPGP digital signature

Re: [HACKERS] PL/pgSQL, RAISE and error context

[Joe Conway]

On 09/05/2015 09:14 AM, Joe Conway wrote:
> On 09/05/2015 09:05 AM, Tom Lane wrote:
>> I wrote:
>>> If there are not major objections, I'll work on cleaning up and
>>> committing the patch.
>>
>> Pushed.  I'm not too sure about the expected outputs for python other
>> than 2.6, nor for sepgsql, but hopefully the buildfarm will provide
>> feedback.
> 
> We don't have the buildfarm actually checking sepgsql yet, but I'll
> check it out manually today or tomorrow.


One-liner required for sepgsql -- attached committed and pushed.

Joe

-- 
Crunchy Data - http://crunchydata.com
PostgreSQL Support for Secure Enterprises
Consulting, Training, & Open Source Development
diff --git a/contrib/sepgsql/expected/label.out b/contrib/sepgsql/expected/label.out
index c84aef7..7af5189 100644
--- a/contrib/sepgsql/expected/label.out
+++ b/contrib/sepgsql/expected/label.out
@@ -156,6 +156,7 @@ LOG:  SELinux: allowed { execute } scontext=unconfined_u:unconfined_r:sepgsql_re
 LOG:  SELinux: allowed { entrypoint } scontext=unconfined_u:unconfined_r:sepgsql_regtest_user_t:s0 tcontext=system_u:object_r:sepgsql_trusted_proc_exec_t:s0 tclass=db_procedure name="function f3()"
 LOG:  SELinux: allowed { transition } scontext=unconfined_u:unconfined_r:sepgsql_regtest_user_t:s0 tcontext=unconfined_u:unconfined_r:sepgsql_trusted_proc_t:s0 tclass=process
 ERROR:  an exception from f3()
+CONTEXT:  PL/pgSQL function f3() line 2 at RAISE
 SELECT f4();			-- failed on domain transition
 LOG:  SELinux: allowed { execute } scontext=unconfined_u:unconfined_r:sepgsql_regtest_user_t:s0 tcontext=system_u:object_r:sepgsql_nosuch_trusted_proc_exec_t:s0 tclass=db_procedure name="public.f4()"
 LOG:  SELinux: allowed { entrypoint } scontext=unconfined_u:unconfined_r:sepgsql_regtest_user_t:s0 tcontext=system_u:object_r:sepgsql_nosuch_trusted_proc_exec_t:s0 tclass=db_procedure name="function f4()"


signature.asc
Description: OpenPGP digital signature

Re: [HACKERS] exposing pg_controldata and pg_config as functions

[Joe Conway]

On 09/02/2015 02:54 PM, Alvaro Herrera wrote:
> Josh Berkus wrote:
>> On 09/02/2015 02:34 PM, Alvaro Herrera wrote:
>>> I think trying to duplicate the exact strings isn't too nice an
>>> interface.
>>
>> Well, for pg_controldata, no, but what else would you do for pg_config?
> 
> I was primarily looking at pg_controldata, so we agree there.
> 
> As for pg_config, I'm confused about its usefulness -- which of these
> lines are useful in the SQL interface?  Anyway, I don't see anything
> better than a couple of text columns for this case.

There are production environments where even the superuser has no
direct, local, command line access on production database servers (short
of intentional hacking, which would be frowned upon at best), and the
only interface for getting information from postgres is via a database
connection. So to the extent pg_config and pg_controldata command line
binaries are useful, so is the ability to get the same output via SQL.

Given that, my own feeling is that if we provide a SQL interface at all,
it ought to be pretty much the exact same output as the command line
programs produce.

To the extent that we want specific pg_controldata output in non-text
form, we should identify which items those are and provide individual
functions for them.

Joe

-- 
Crunchy Data - http://crunchydata.com
PostgreSQL Support for Secure Enterprises
Consulting, Training, & Open Source Development



signature.asc
Description: OpenPGP digital signature

Re: [HACKERS] PL/pgSQL, RAISE and error context

[Joe Conway]

On 09/05/2015 09:05 AM, Tom Lane wrote:
> I wrote:
>> If there are not major objections, I'll work on cleaning up and
>> committing the patch.
> 
> Pushed.  I'm not too sure about the expected outputs for python other
> than 2.6, nor for sepgsql, but hopefully the buildfarm will provide
> feedback.

We don't have the buildfarm actually checking sepgsql yet, but I'll
check it out manually today or tomorrow.

Joe

-- 
Crunchy Data - http://crunchydata.com
PostgreSQL Support for Secure Enterprises
Consulting, Training, & Open Source Development



signature.asc
Description: OpenPGP digital signature

Re: [HACKERS] exposing pg_controldata and pg_config as functions

[Joe Conway]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

On 09/02/2015 05:25 PM, Tom Lane wrote:
> Robert Haas  writes:
>> But I'm not sure I like the idea of adding a server dependency on
>> the ability to exec pg_controldata.  That seems like it could be 
>> unreliable at best, and a security vulnerability at worst.
> 
> I hadn't been paying attention --- the proposed patch actually
> depends on exec'ing pg_controldata?  That's horrid!  There is no
> expectation that that's installed.

No it doesn't. I'm confused :-/

Joe


- -- 
Crunchy Data - http://crunchydata.com
PostgreSQL Support for Secure Enterprises
Consulting, Training, & Open Source Development
-BEGIN PGP SIGNATURE-
Version: GnuPG v2.0.22 (GNU/Linux)

iQIcBAEBAgAGBQJV52qoAAoJEDfy90M199hltvwP/3MfUQfPPglhBuY1V3CTzHu9
kTw5tNuGI/244Yc11wLtV07W+3QWXzCNY/fL1JCW5ns51mTfZKfkskNWD0O9fIex
gvK4p/3Z+y344qsdDlzbzw0A/PU05UCq1UlgXCF6nyQJW6cZfaCckbEpZWVK/uV7
aYokIqnIiilWaPu224b6jBOukK7oizEjXevdFBafLbetLJHMx+9k8LMbpPdieAm/
RSk17+N77WQ2zTFHcdz8U1MYAbaokmv155s1vUFgrqOUJGc0r6K+vImKgxOjbbmg
pv2jf7vvUwwjUy7f2iPhWJAKfGCV1m9ovWaXsMYqcF55JwSzvP8B2htUtM4Lr1qF
SsWO7e36bLoH++yAGfKp7oZIhA9r6SR6cwEoCvso3immZ2zhOzbRcw4tI4pE9fhB
P/mEbKFF5BsGHjeslB8RrMQG68DxEwPkaafH4mc1QjKiXNfWPH9ci+pgfSLVphJq
gn+ZuPrReIFhQKyMchcvZVVWJd9Dt02D2lsIzUfBWGXwOTLFVikD6BC6siy5KWmy
xuEGLEfts9E7gPD3qPXxNuY7TCvb+L7R+1C9/M5diiV7rerMUocH/RqrPP6nXHTc
BdfJhzOfU+H+Kt0nbdE8Vjw3BOKT6nqT0kc+le+F/Q1h2XLB63KhaOkFzVW73Rfd
JRRqkyks+eVgEn2I4OKm
=OAms
-END PGP SIGNATURE-


-- 
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers

Re: [HACKERS] One question about security label command

[Joe Conway]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

On 08/28/2015 07:21 PM, Adam Brightwell wrote:
 On 08/28/2015 08:37 AM, Joe Conway wrote:
 So given all that, here is what I propose we do:
 
 1.) Commit Kouhei's patch against HEAD and 9.5 (Joe) 2.) Commit
 my modified patch against 9.4 and 9.3 (Joe) 3.) Rework patch for
 9.2 (Kouhei) 4.) Finish standing up the RHEL/CentOS 7.x buildfarm
 member to test sepgsql on 9.2 and up. The animal (rhinoceros) is
 running already, but still needs some custom scripting. (Joe,
 Andrew) 5.) Additionally stand up a RHEL/CentOS 6.x buildfarm
 member to test sepgsql on 9.1 (no changes) (Joe).
 
 Sound like a plan?
 
 I think this makes sense.  Getting buildfarm coverage on any level
 is better than nothing, IMHO.  Kind of a bummer that 9.1 is the
 only version that will work as-is on EL6 but it is what it is for
 now, I suppose.

#1 and 2 above are done -- committed and pushed to HEAD and 9.3-9.5.

Additionally I have #5 (the 6.x buildfarm member) created/working and
I sent in my registration form. It has not been accepted yet.

Joe

- -- 
Crunchy Data - http://crunchydata.com
PostgreSQL Support for Secure Enterprises
Consulting, Training,  Open Source Development
-BEGIN PGP SIGNATURE-
Version: GnuPG v2.0.22 (GNU/Linux)

iQIcBAEBAgAGBQJV40i4AAoJEDfy90M199hlFK4P/iBkQk1oboo9OlnRgIT3w/be
tCoL95E3ZH7SPEuxq0lbbCM6Hvz5lFWw0X9RQBJlUFBaIPjoilGrcf8r6COSfZZt
XOTwmQJMDO7iCmBuc89ZrVH5Fz3rc19eA6p7bNplwesWOtXP/RwRObjtffi2XHOz
pOuUqHpw9GBK4uVEf7v9Fdqz48OUYGa/MAMlw3XlBzgBKdx8l+bjBh/5YQFvRwBr
ujNb9c/1DfEvtr/oaa7rmkKNUVmL53bEZbL6m81+taCKbvt7yD5GAN5Sdqw27iiy
HILGwmdzlVzd+VMIJ7+53w2HpimIEVXCnn2yrM1rWL12b9oFmz/rCA1qfuyrGIN9
9ZFb+q3myCq/ofzXoznsBUIYxQhAfuLyRDrAUPEi8h4wWDc3JPJJkKmu/6ZuBGv7
m2g3mUx9sr7BoJKVZ4Vkqc4mgorwDkwzfJpiH0hKBewtO3WkN8LHk/jGTZaPgMwl
4OjJQvmCBk/5vdsfOQ/qZHqw6WM75gnxKGvHo/nFPuztzawXVx4sVWm2e4HxZlAP
tfrTZtAYTE1K5y6Kn6yIeQgW4ZTwztIsjuG0XebTAymnHIjqkkj5RHpn93PADbrh
wHvs6+nQAePdWoQ2LPwlWNELUxRz107BMnWBCHYk+cqoim48GE0UIHTLZQtR7C5D
wIo5lU81nUqPI147940K
=AB+P
-END PGP SIGNATURE-


-- 
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers

Re: [HACKERS] One question about security label command

[Joe Conway]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

On 08/25/2015 06:54 PM, Joe Conway wrote:
 On 08/25/2015 06:03 PM, Joe Conway wrote:
 I'm arriving late to this party, so maybe everyone else already 
 knows this, but apparently sepgsql is not compatible with the 
 version of selinux available on RHEL 6.x. So there doesn't seem
 to be much reason for a RHEL 6.x buildfarm animal just for
 sepgsql testing as it will always fail ;-)
 
 Just to be clear, I have marked this on the commitfest app as
 ready for commit, and plan to commit it soon. Figuring out the
 buildfarm animal will be my next task after that.

Here's a synopsis of the state of play with respect to sepgsql
regression tests:

Required
PG Ver  RHEL Ver*   test w/patchtest w/o patch
- ---   --
HEAD   7.x  OK   NOK
9.57.x  OK   NOK
9.47.x  OK** NOK
9.37.x  OK** NOK
9.27.x  NOK  NOK
9.16.x  NOK  OK
9.0*** N/A  N/A  N/A
- ---   --
* It is really the version of libselinux.so that matters here. RHEL
7.x has libselinux 2.2.x whereas RHEL 6.x has 2.0.x. The latter lacks
functionality required by sepgsql starting with PG 9.2.
** As noted in an earlier message on this thread by Adam, with PG 9.4
(and 9.3) there is some addition noise coming from differences in
default verbosity or possibly error context hiding added after 9.4,
which causes the regression to fail with Kouhei's patch. Attached is a
slightly modified patch that works for 9.4 and 9.3.
*** sepgsql was introduced in PG 9.1

So given all that, here is what I propose we do:

1.) Commit Kouhei's patch against HEAD and 9.5 (Joe)
2.) Commit my modified patch against 9.4 and 9.3 (Joe)
3.) Rework patch for 9.2 (Kouhei)
4.) Finish standing up the RHEL/CentOS 7.x buildfarm member to
test sepgsql on 9.2 and up. The animal (rhinoceros) is running
already, but still needs some custom scripting. (Joe, Andrew)
5.) Additionally stand up a RHEL/CentOS 6.x buildfarm member to test
sepgsql on 9.1 (no changes) (Joe).

Sound like a plan?

Joe
- -- 
Crunchy Data - http://crunchydata.com
PostgreSQL Support for Secure Enterprises
Consulting, Training,  Open Source Development
-BEGIN PGP SIGNATURE-
Version: GnuPG v2.0.22 (GNU/Linux)

iQIcBAEBAgAGBQJV4IA5AAoJEDfy90M199hlF6wP/1p0xpVORBY4DLjLaM8KzAWt
HxZjtK6vD8yQCG45L1crhYnB2FYIHZoG+71WwP7xSZ6YnOC+g5mFrjh6YdRMxwSe
OSnMIuy7QvVZrGfvSSIG6u4lBivi9jDC6mnFuU5YW9Q3mk6HBdJbErIuwP3z0Bxj
c9yuh6WqWRNghVwIyErkdbp7YqFDeoQZ8iSiKxDghMIQRzFgB4K1egEDM6TGAo/1
/1j0vSLmRoQPZvDnJaLCAsZzw7JozppwCXPwfpwd2Xj6N3h/v9aoflRKaKppvf16
vIqDcHkdbea3Bk/jGS3OBBMBXDsd5lrfjF5iaFVtiBu04VjUaJJ0mHOKNL+xf4Uk
E9C8bjxpR7MEeiR8tE8RTMWg710ITVix3P8I3y+LS0V8GhzaHw2AOKSlGVNlRf/Y
VfoFEcvqcqsnenA3gmUbljSeHI0G3G5w+nTwEvciug28PffnpNyamtjPOn4IEay4
12RrbD/v7IfsXxjnDqhQRLdy1t7tVDjNC6ddjSfT3G64v4pvBoSaT9NQXWJ9jw3A
aM345gguBRVGcKRD/UZfUZ4VBesj5T67g56HPmEqDC+7LlqVBSmKdEJ51RrfRsKF
fd8OZT43h9+XXD4yCuxt0bt38ybiRsOAdjT4eUrTj18GGx0q3P08NNnZI2V0fe4b
/8pM9IlcdxDYGS7e3oPv
=SbW3
-END PGP SIGNATURE-
diff --git a/contrib/sepgsql/expected/alter.out b/contrib/sepgsql/expected/alter.out
index 124f862..e67cc2d 100644
--- a/contrib/sepgsql/expected/alter.out
+++ b/contrib/sepgsql/expected/alter.out
@@ -8,9 +8,9 @@ DROP DATABASE IF EXISTS regtest_sepgsql_test_database;
 DROP USER IF EXISTS regtest_sepgsql_test_user;
 RESET client_min_messages;
 SELECT sepgsql_getcon();	-- confirm client privilege
-  sepgsql_getcon   

- unconfined_u:unconfined_r:unconfined_t:s0
+  sepgsql_getcon  
+--
+ unconfined_u:unconfined_r:sepgsql_regtest_superuser_t:s0
 (1 row)
 
 --
@@ -40,140 +40,136 @@ SET client_min_messages = LOG;
 --  owner is not actually changed.
 --
 ALTER DATABASE regtest_sepgsql_test_database_1 OWNER TO regtest_sepgsql_test_user;
-LOG:  SELinux: allowed { setattr } scontext=unconfined_u:unconfined_r:unconfined_t:s0 tcontext=unconfined_u:object_r:sepgsql_db_t:s0 tclass=db_database name=regtest_sepgsql_test_database_1
+LOG:  SELinux: allowed { setattr } scontext=unconfined_u:unconfined_r:sepgsql_regtest_superuser_t:s0 tcontext=unconfined_u:object_r:sepgsql_db_t:s0 tclass=db_database name=regtest_sepgsql_test_database_1
 ALTER DATABASE regtest_sepgsql_test_database_1 OWNER TO regtest_sepgsql_test_user;
-LOG:  SELinux: allowed { setattr } scontext=unconfined_u:unconfined_r:unconfined_t:s0 tcontext=unconfined_u:object_r:sepgsql_db_t:s0 tclass=db_database name=regtest_sepgsql_test_database_1
+LOG:  SELinux: allowed { setattr } scontext=unconfined_u:unconfined_r:sepgsql_regtest_superuser_t:s0 tcontext

Re: [HACKERS] exposing pg_controldata and pg_config as functions

[Joe Conway]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

On 08/26/2015 06:33 AM, Stephen Frost wrote:
 * Joe Conway (m...@joeconway.com) wrote:
 Issues needing comment: a.) Which items need hiding from
 non-superusers and should the value be redacted or the entire
 result set row be suppressed?
 
 I'm of the opinion that we need to at least redact it and that what
 we should do is simply suppress the entire result set until we
 provide a way for administrators to manage who can access it (eg:
 default roles, this one would fall under 'pg_monitor', imo).

Whatever it is it would have to be available during initdb. And in any
case I'm no closer to knowing which rows to hide/redact/suppress other
than WAL position. Possibly the thing to do for now would be to revoke
public from these?

Joe
- -- 
Crunchy Data - http://crunchydata.com
PostgreSQL Support for Secure Enterprises
Consulting, Training,  Open Source Development
-BEGIN PGP SIGNATURE-
Version: GnuPG v2.0.22 (GNU/Linux)

iQIcBAEBAgAGBQJV3c3nAAoJEDfy90M199hlMnYQAJliTc7bJTCndMQ0emN6xV55
DqODtxABxh3kqPmWcvSO08dSZ5yHpCKYgIm8OmRIpfDUwNID1uBXsO5pRd1XVzLr
42OmQ9QauAZ9+f/Rea668U/zgzhnIJXdVsFfAmum516UoR3W1rqW5ggPKgN5YDhC
9Z6ikL1fs6l6l1yrvaefbepS1FLx6wDplhctN+hbEdHw9gwAf67fv7ncaPZ4BRyc
hogL4mXoz0fFQz7RDvnR2g0uu17k3imbwzqGiyJwH4+9cfnNLWrBXupKwC06ufWF
t3cLh4lLTUhx/2amB0qKMQp1MgVs6r70f5ciFTWvaO0nro0wSGHnIsnqFDOfnv2X
kctZreHs7gDAFXWM4Qp45oxTHy6Lfce75IvDfZGZ3y8NOhEHZDqJs6VIdOgCu4h0
RkJE/RrRz7ZtMAhyokxWMZvffYRutLPbXAUvg6TBeDVy1T7SKoQK81IBz/Nkd+Bm
WkB/EFklUZw/B2HnDpXRV3tdjAzMAJw22bQi0Y7515K25w7NC2nquzX1eBMGmaqe
yDf/gobFg601E9WMjaNoxMGy3Niigk46UsQLGT7RJ/ciojY1gGQh/qd4b1BeJpM0
kRmj0Jsyn0cO8hs6h7jBNBVJjlBhr9ijd4tWaZAk9XqLExPPmGunhcoOMf6ttmvy
533U1P2OKyGBZZissMd4
=dlGD
-END PGP SIGNATURE-


-- 
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers

Re: [HACKERS] pg_controldata output alignment regression

[Joe Conway]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

On 08/24/2015 07:41 PM, Tom Lane wrote:
 Joe Conway m...@joeconway.com writes:
 Do we care that as of 9.5 pg_controldata output is not 100%
 aligned anymore? The culprit is: Current track_commit_timestamp
 setting: off Its value is shifted 2 characters to the right with
 respect to all the others. I think it ought to be fixed but
 thought I'd get opinions first.
 
 Seems to me we could s/Current //g, or s/ setting//g, or both, and
 get rid of the problem without adding more whitespace.

I'd agree, except I think not everyone might be happy with that. The
surrounding lines look like:

8
...
End-of-backup record required:no
Current wal_level setting:minimal
Current wal_log_hints setting:off
Current max_connections setting:  100
Current max_worker_processes setting: 8
Current max_prepared_xacts setting:   0
Current max_locks_per_xact setting:   64
Current track_commit_timestamp setting: off
Maximum data alignment:   8
Database block size:  8192
...
8

So while changing that line to this would work...

8
...
Current max_locks_per_xact setting:   64
track_commit_timestamp setting:   off
Maximum data alignment:   8
...
8

... it does become inconsistent with the ones above.

One possible solution is to abbreviate Current for all of them as
Cur.:

8
...
End-of-backup record required:no
Cur. wal_level setting:   minimal
Cur. wal_log_hints setting:   off
Cur. max_connections setting: 100
Cur. max_worker_processes setting:8
Cur. max_prepared_xacts setting:  0
Cur. max_locks_per_xact setting:  64
Cur. track_commit_timestamp setting:  off
Maximum data alignment:   8
Database block size:  8192
...
8

Of course that breaks backward compatibility if you believe it is
important here. Otherwise maybe:

8
...
End-of-backup record required:no
Current wal_level setting:minimal
Current wal_log_hints setting:off
Current max_connections setting:  100
Current max_worker_processes setting: 8
Current max_prepared_xacts setting:   0
Current max_locks_per_xact setting:   64
Cur. track_commit_timestamp setting:  off
Maximum data alignment:   8
Database block size:  8192
...
8


Joe

- -- 
Crunchy Data - http://crunchydata.com
PostgreSQL Support for Secure Enterprises
Consulting, Training,  Open Source Development
-BEGIN PGP SIGNATURE-
Version: GnuPG v2.0.22 (GNU/Linux)

iQIcBAEBAgAGBQJV3KUiAAoJEDfy90M199hlPmAP+wSn1w+l4YhPlkuk0tZVN5Vl
LpmXD3uGi0WXrt21jQgCaXdj3QeLPzrK9Pu5QDyHODpGexZ7j1lJiTl0cXxQ8CuK
LwyPlNr5nzoRGru+g4aRElzGr1unSPI4K8m7nVH2KTw/mmByR+RCQu6CPGqnOZ1+
4EtW/9svO4hw+YxhjRRdyQwP7XVhI1Og4jryp6kOdzmYbO0K+uMZo8+xFvRg4Sr5
u7iyJe1xUgrsqQhvbRh+eguV0+d/ykDGgodEEPfEEcmvxxQEDvhQ9STM8eEEoK1v
sz1/ObFbJ3GrzVZB5Mse6+uFwQB6JqJBvCrnkuH43d9U2NKikR5vm8VJ48yxvwd7
VZLXodAQmudlt0nJdL7vRGoOBt/gztSkuWvl+4y206GRdWcvkNFKTKyvnpoZdW+7
KIaz0D2mWeC/Hr5j84pTLPcfF3ezz+HdUHDmuSt7HX+fH3CSzhGlcoCMZdgZIIKM
1a2RHN8r3sF0U/hyKFjpFetq28Pgnrhardn7Y4U4qveCfwRopF4grNYYrfqreQ0a
xxi0bXb81iWX5HvvnWh82/NmG9qH+YhLaHqovvR/5+iXKpcv1do+oSVz0uKwaSen
4gcE7JiWELrhp6+iftzt2U0X69Xd5KeluScjaxeOaQsAYW53pHvOLk5c56RrHVim
WZiPEkdGZffETA0SCaZL
=hV8z
-END PGP SIGNATURE-


-- 
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers

Re: [HACKERS] pg_controldata output alignment regression

[Joe Conway]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

On 08/25/2015 10:28 AM, Tom Lane wrote:
 Joe Conway m...@joeconway.com writes:
 On 08/24/2015 07:41 PM, Tom Lane wrote:
 Seems to me we could s/Current //g, or s/ setting//g, or both,
 and get rid of the problem without adding more whitespace.
 
 I'd agree, except I think not everyone might be happy with that.
 The surrounding lines look like:
 
 I was suggesting getting rid of Current in *all* the entries.
 What value does it add?

I agree, it adds no value, and is a simple solution.

Does anyone out there object to a non-backward compatible change to
pg_controldata output?

Joe

- -- 
Crunchy Data - http://crunchydata.com
PostgreSQL Support for Secure Enterprises
Consulting, Training,  Open Source Development
-BEGIN PGP SIGNATURE-
Version: GnuPG v2.0.22 (GNU/Linux)

iQIcBAEBAgAGBQJV3KaTAAoJEDfy90M199hlv+gP/Rgbhvj6Vg06zPokyUXTLMiw
LHmZedhOv2XaPW5e1uj7P/8d4y+NjSt7bWnQ2P6ONqNk9SkgQTGS1QIlvShUQDAj
312Lct83xYnJrukBfqzLoeDavPM7GPUiJal4yEixREDYElNa7bwTO/bIFWuAdx9F
xJYAwLsWW9AnbTroRn4pgOTpr9YvP/pk0WS7s1wQCmMKbyBRtTYb2yfn+p2NYJS1
/nFJPzIzuRjjVH4U43PZuWuESoW5RUKQQXYQn6FdrgcBPRMWA02blzRTKvuuX19T
XXqb0HS+Ge8QpeqofAW6RuCHsvHClYex99PfCyUCAf6t9HOpY6w/dd2RWqExw8zV
TrhSJnB0gVI0dONXrew/AwhTc4hy6oeHkSDZd/h6RldwrUMspXbDrjBdmUIo66Dq
SinE9OrBXbS2lbDPMmYIWJLbkHn2bjKi8Bs3yBSxmqCnZclAHQefF5TqcxYRB3gD
+U0QGuAcCjmKVGE+q33DnIUdSe64uBKP0zRpEWpHw3ENrtwgqR3dfrsTZwLxtMij
R6XCOOJQEIw8Gh3nULxwk4sar7zFG+hQqGcZ5IHlAvj4Cjis67qMLTqXyBItQP7x
TrVn+UJv4J0t1lCYAt1Cxv11kVictiqBzS1E9JcOJBhAgQguh88HddlnWmj1kVBi
lryNq+HsH/lZbc0HwkB9
=crEM
-END PGP SIGNATURE-


-- 
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers

Re: [HACKERS] Commitfest remaining Needs Review items

[Joe Conway]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

On 08/25/2015 12:39 AM, Michael Paquier wrote:
 -- self-defined policy for sepgsql regression test, returned with 
 feedback? The regressions are broken as mentioned at the end of
 the thread.

I am in the process of getting a VM setup with an appropriate SELinux
setup to look at this one. Will hopefully be able to provide more
feedback in a day or two.

Joe

- -- 
Crunchy Data - http://crunchydata.com
PostgreSQL Support for Secure Enterprises
Consulting, Training,  Open Source Development
-BEGIN PGP SIGNATURE-
Version: GnuPG v2.0.22 (GNU/Linux)

iQIcBAEBAgAGBQJV3HdkAAoJEDfy90M199hlMggQAKfKGJrKzSkdEACoMy83KPAY
UBLPtoFr7ay6c8eS13ahlW6xehIeQoSp1COftYOIO0qFo4JN3+NOJCVGvmS+ooG+
HbGkP919urG10QB3REWp4J6gdnKjIhuAq2cQZQRFBSVPVWqKTBDGUL6RRWDkRwtq
ytWqOLnXb6FTidBihi1hBmV12z9z1FDujMntBMyzIrGpcCcnQ0KDeDXM7kkQeOU7
dMs2m1b2PijToI9UEtWI5lBldhFH/UUSVtBAKQ0BQtAJaLgs2BknIEuj4zwswzEx
IUG7Q+zD4RijkYePVw/gqeHW24g5rSvAC6lmvSpF5L7Cnr2bP1ZXedcInWcRGafT
8IhW1Sggmjd9ZP3EOO/9cEKG50cZpqbdDWdUZciAG0MTbAvOByMyMP49ckyO49T9
XLyUj8lCL1Hoocl203DAJouUr24HOOxd2IcfqYRa64B0jlWUwqi9j1E+DofBMJc+
wUOYrpsQ0/r0YOxNQppfiHX0NxIkp2RCI2dmmNHt2JjlqNME4YH1o2RHby7OwiBb
7kE5WUz7MTJrN7vg9Ua0DvJEBJ1YihOl7mjnlXgJ6ZoXih/l2Jq7LrrlohQlfHeZ
lpSqeVUTu7HkBm0zicwgGna9dzeXpnUrTrlvFH9Wsr7//9kmrfHi8Kt8lASKeQ4d
7YwaThj0oAp4sVsFW39Z
=WGIF
-END PGP SIGNATURE-


-- 
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers

Re: [HACKERS] exposing pg_controldata and pg_config as functions

[Joe Conway]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

On 08/24/2015 08:52 AM, Joe Conway wrote:
 On 08/24/2015 06:50 AM, Tom Lane wrote:
 Andrew Dunstan and...@dunslane.net writes:
 On 08/23/2015 08:58 PM, Michael Paquier wrote:
 I think that's a good thing to have, now I have concerns
 about making this data readable for non-superusers. Cloud
 deployments of Postgres are logically going to block the
 access of this view.
 
 I don't think it exposes any information of great security 
 value.
 
 We just had that kerfuffle about whether WAL compression posed a 
 security risk; doesn't that imply that at least the data
 relevant to WAL position has to be unreadable by non-superusers?
 
 So pg_config might be fully unrestricted, but pg_controldata might 
 need certain rows filtered based on superuser status? Do you think 
 those rows should be present but redacted, or completely filtered
 out?

Here is the next installment on this. It addresses most of the
previous comments, but does not yet address the issue raised here by Tom
.

Changes:
1.) pg_controldata() function and pg_controldata view added

2.) cleanup_path() moved to port/path.c

3.) extra PG_FUNCTION_INFO_V1() noise removed

Issues needing comment:
a.) Which items need hiding from non-superusers and should the value be
redacted or the entire result set row be suppressed?

b.) There is a difference in the formatting of timestamps between the
pg_controldata binary and the builtin function. To see it do:

  diff -c (pg_controldata) \
  (psql -qAt -c select rpad(name || ':', 38) || setting
  from pg_controldata)

What I see is:

pg_controldata
! pg_control last modified: Tue 25 Aug 2015 08:10:42 PM PDT
pg_controldata()
! pg_control last modified: Tue Aug 25 20:10:42 2015

Does it matter?

c.) There is some common code between pg_controldata.c in bin and
pg_controldata.c in backend/utils/misc. Specifically the string
definitions in printf statements match those in ControlData[], and
dbState() and wal_level_str() are in both places. Any opinions
on consolidating them in src/common somewhere?

d.) Still no docs yet - will get to it eventually.

Thanks,

Joe

- -- 
Crunchy Data - http://crunchydata.com
PostgreSQL Support for Secure Enterprises
Consulting, Training,  Open Source Development
-BEGIN PGP SIGNATURE-
Version: GnuPG v2.0.22 (GNU/Linux)

iQIcBAEBAgAGBQJV3TNnAAoJEDfy90M199hl0OsQAIyTr0hqxwjrGenDpnS4qE8u
UJWVeCpqehFIobxcJ0TICTaQX835fzPGJIiTUwI1Dmz9sgjipvSG1wBmD4bRT93X
WO4e/+Yr5onZ9vNVXlUswPK2kuzehImhmzMSnJ6KDXKkfw2MOZmz56wBb3yIB3lq
K44FDukZ01w9RCGM8H5B/MPNMHIqfBB4wdlKARJZhqeUyPvTJ71iMiqeE77v3AIH
JLmW6kRw8c3NVu/Wa+GVz4FGjIZKR5oazlFYfDTeHXrxV8NIDUFNrKikAW1ScdVK
qSPVjFxoUlbX4W2dd1L1ciGeq83DktYbdKtpZZScQGXwhuq7Y1fHZQwzlxlraB/c
UiqNdxmi7IeUdOIncsKPDmjs7C5yeNj1CRnWHTAQRW98RM42A3TvT2Qlkxm0CVLQ
lZjFVOOMIf4pXYQv6PfiicO6QWYTUSXCa891s/10H2xkS/sMK1yHz3DWSZxVdDdI
dbh5gie/GFro1nwWd8gjkn5KCe917GDBAUBn+QE5TgUPnRhserq6FQBSyVXfZtOQ
o6nRM8vuv9Y06CRoeIgagtDWxippl0OAw442wHyme/PBQZ2842PW8GNNqw+B1HWz
Ir0V5FiZdLLQipwiKT152+8OsOa/NU6wxGFuJr8It/4471h3jU5dxuHO+wQqMDEb
xCn6ebwZaa9oSjHFrfy3
=oMOO
-END PGP SIGNATURE-
diff --git a/src/backend/catalog/system_views.sql b/src/backend/catalog/system_views.sql
index ccc030f..7b5db32 100644
*** a/src/backend/catalog/system_views.sql
--- b/src/backend/catalog/system_views.sql
*** CREATE VIEW pg_timezone_abbrevs AS
*** 425,430 
--- 425,436 
  CREATE VIEW pg_timezone_names AS
  SELECT * FROM pg_timezone_names();
  
+ CREATE VIEW pg_config AS
+ SELECT * FROM pg_config();
+ 
+ CREATE VIEW pg_controldata AS
+ SELECT * FROM pg_controldata();
+ 
  -- Statistics views
  
  CREATE VIEW pg_stat_all_tables AS
diff --git a/src/backend/utils/misc/Makefile b/src/backend/utils/misc/Makefile
index 7889101..13b60f7 100644
*** a/src/backend/utils/misc/Makefile
--- b/src/backend/utils/misc/Makefile
*** include $(top_builddir)/src/Makefile.glo
*** 14,21 
  
  override CPPFLAGS := -I. -I$(srcdir) $(CPPFLAGS)
  
! OBJS = guc.o help_config.o pg_rusage.o ps_status.o rls.o \
!sampling.o superuser.o timeout.o tzparser.o
  
  # This location might depend on the installation directories. Therefore
  # we can't subsitute it into pg_config.h.
--- 14,34 
  
  override CPPFLAGS := -I. -I$(srcdir) $(CPPFLAGS)
  
! # don't include subdirectory-path-dependent -I and -L switches
! STD_CPPFLAGS := $(filter-out -I$(top_srcdir)/src/include -I$(top_builddir)/src/include,$(CPPFLAGS))
! STD_LDFLAGS := $(filter-out -L$(top_builddir)/src/port,$(LDFLAGS))
! override CPPFLAGS += -DVAL_CONFIGURE=\$(configure_args)\
! override CPPFLAGS += -DVAL_CC=\$(CC)\
! override CPPFLAGS += -DVAL_CPPFLAGS=\$(STD_CPPFLAGS)\
! override CPPFLAGS += -DVAL_CFLAGS=\$(CFLAGS)\
! override CPPFLAGS += -DVAL_CFLAGS_SL=\$(CFLAGS_SL)\
! override CPPFLAGS += -DVAL_LDFLAGS=\$(STD_LDFLAGS)\
! override CPPFLAGS += -DVAL_LDFLAGS_EX=\$(LDFLAGS_EX)\
! override CPPFLAGS

Re: [HACKERS] pg_controldata output alignment regression

[Joe Conway]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

On 08/25/2015 10:32 AM, Joe Conway wrote:
 On 08/25/2015 10:28 AM, Tom Lane wrote:
 I was suggesting getting rid of Current in *all* the entries. 
 What value does it add?
 
 I agree, it adds no value, and is a simple solution.
 
 Does anyone out there object to a non-backward compatible change
 to pg_controldata output?

...specifically the attached. Will commit/push to 9.5 and HEAD in a
few hours barring any objections.

Joe

- -- 
Crunchy Data - http://crunchydata.com
PostgreSQL Support for Secure Enterprises
Consulting, Training,  Open Source Development
-BEGIN PGP SIGNATURE-
Version: GnuPG v2.0.22 (GNU/Linux)

iQIcBAEBAgAGBQJV3LM6AAoJEDfy90M199hlzwUP/0EeobxsxidorFS/4RQRXeWN
Gb879a7brwAIuEZVqP9BdlzhfPWrGx98vyRHvQ4jbcNXXO3fe5xTqklXdSMAJD5L
0hF1+DIVHg+SuZ7hJiW0wl1y0b8OIs2w7WOHwi39ZFV1//dbJkV8DkWG0Ty2Roxf
JXqBrFOLP0nu6sS3jx2tCkGtkAL5b0FvZw6aFiuxvVUYFW8U36VjCVgZ6aEN+7Jn
zvMrMsBtH/AxfhPWd8BblsBhC3+ShPPdG8rE9RHSBwX6qBWlJnf3WAiEjuj6p7Wk
kQluJwxWU13s/IKjqmES+H04fEUeqTNouRDlCEKim7o5d7E1FNDS0gCcQ0oIftco
dtTf192K91+xtnsnQrgODkrk/tZpnCr7ay0LHI+ydIOtmqgX1g3RchoTL37zMohK
sDLEo3aTM4f6mLV2Qbh9ETizcssJuZJoSKKo51icLxbXXUrv8CuU5yniXAm8NM0a
MwyVfJL3gjQhEcP3aRIbvCRVqtQJK2Y8Qiff5uDQ+9Nl3ApdIVuyEp+w9pvK/55Z
w3MdZt5cjphIANjayqfA2B4nSvLE3RC7caJr0HS10yvFAzP2Go4HQUA1t7RFCYI0
zww+ZQ2hrIdiSZu61QnO1DR49WZrQPd1Z/W9gzHHqTFO1IYf+XxBliQk0mTbZUiN
v2DJhvBV2zMhS0jjrVvV
=6223
-END PGP SIGNATURE-
diff --git a/src/bin/pg_controldata/pg_controldata.c b/src/bin/pg_controldata/pg_controldata.c
index d8cfe5e..046480c 100644
*** a/src/bin/pg_controldata/pg_controldata.c
--- b/src/bin/pg_controldata/pg_controldata.c
*** main(int argc, char *argv[])
*** 290,308 
  		   (uint32) ControlFile.backupEndPoint);
  	printf(_(End-of-backup record required:%s\n),
  		   ControlFile.backupEndRequired ? _(yes) : _(no));
! 	printf(_(Current wal_level setting:%s\n),
  		   wal_level_str(ControlFile.wal_level));
! 	printf(_(Current wal_log_hints setting:%s\n),
  		   ControlFile.wal_log_hints ? _(on) : _(off));
! 	printf(_(Current max_connections setting:  %d\n),
  		   ControlFile.MaxConnections);
! 	printf(_(Current max_worker_processes setting: %d\n),
  		   ControlFile.max_worker_processes);
! 	printf(_(Current max_prepared_xacts setting:   %d\n),
  		   ControlFile.max_prepared_xacts);
! 	printf(_(Current max_locks_per_xact setting:   %d\n),
  		   ControlFile.max_locks_per_xact);
! 	printf(_(Current track_commit_timestamp setting: %s\n),
  		   ControlFile.track_commit_timestamp ? _(on) : _(off));
  	printf(_(Maximum data alignment:   %u\n),
  		   ControlFile.maxAlign);
--- 290,308 
  		   (uint32) ControlFile.backupEndPoint);
  	printf(_(End-of-backup record required:%s\n),
  		   ControlFile.backupEndRequired ? _(yes) : _(no));
! 	printf(_(wal_level setting:%s\n),
  		   wal_level_str(ControlFile.wal_level));
! 	printf(_(wal_log_hints setting:%s\n),
  		   ControlFile.wal_log_hints ? _(on) : _(off));
! 	printf(_(max_connections setting:  %d\n),
  		   ControlFile.MaxConnections);
! 	printf(_(max_worker_processes setting: %d\n),
  		   ControlFile.max_worker_processes);
! 	printf(_(max_prepared_xacts setting:   %d\n),
  		   ControlFile.max_prepared_xacts);
! 	printf(_(max_locks_per_xact setting:   %d\n),
  		   ControlFile.max_locks_per_xact);
! 	printf(_(track_commit_timestamp setting:   %s\n),
  		   ControlFile.track_commit_timestamp ? _(on) : _(off));
  	printf(_(Maximum data alignment:   %u\n),
  		   ControlFile.maxAlign);

-- 
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers

Re: [HACKERS] pg_controldata output alignment regression

[Joe Conway]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

On 08/25/2015 11:28 AM, Alvaro Herrera wrote:
 Joe Conway wrote:
 
 Does anyone out there object to a non-backward compatible change
 to pg_controldata output?
 
 I don't (and thanks for taking care of it), but as I recall,
 pg_upgrade reads and interprets pg_controldata output so it may
 need adjustment too.

Thanks for the heads up. There are lots of controldata items
pg_upgrade is interested in, but AFAICS none of these are included.
Now maybe they should be, but they are not currently referenced.

(Bruce added to the thread:
 we're talking about:
  Current wal_level setting
  Current wal_log_hints setting
  Current max_connections setting
  Current max_worker_processes setting
  Current max_prepared_xacts setting
  Current max_locks_per_xact setting
  Current track_commit_timestamp setting
)

Joe

- -- 
Crunchy Data - http://crunchydata.com
PostgreSQL Support for Secure Enterprises
Consulting, Training,  Open Source Development
-BEGIN PGP SIGNATURE-
Version: GnuPG v2.0.22 (GNU/Linux)

iQIcBAEBAgAGBQJV3MCnAAoJEDfy90M199hli+4P/1fTAXs1yiPga/5MPDoU8yuZ
8mHEvc+6fDXfkb8wk3GEiRjbhenhqkwFhLOBRDCWqKgzLT0rENp8fgm44gnNkim2
cGyz2ZOl5cqVqgZMziiLEhxlojbCLGKB8UOYM2176tBvkxx6NbhY8kjdaOoc6lXX
88n+PWaVdEwaIvYYMGfQjaxgVJxBJBBoRMNjYXhmgqBo3RNE0gwJfjEUNk7VzSnp
w+tWrhgBIsHDyg12PnB/X3Wo5220N8rmN11ShDIUxhG5TJj3+u9W3iLB94lP8U2l
hmdqsLkbYp5sptkYcFW1d3twOvJwqM0TIezLqTsHRWDtL2u0qOF6IGg9KsFBwbLg
g6YcDUUw8UmrX3QmeytKzecbbvi2j1hg8h7kleWG86MwipbX2V1GHohBT3Ih2Srf
Aw4poaYC94VKY+kKpMM+0901JOC064PguT/6Cud6QcujxGWrzzZJWmbbfXSlS+DZ
5xVco7e9XeYGQoA2CfhPiBZc1Mb7ZZYv1ptvK5NW64NQBlgrwQEwSa1YUkLvA+/Y
mlCXgC8/w6A1QE4sRdQKzKqN1MRxcvnZKIVM/F0KepagIxU9IWUBh+qE98LjZWsM
/02fyZPLt1COZnqDQSfGXdA7QgMLOm6Tfl0v3A7iv6qUT+hxiP5TonhPcJk2u0IM
E81K2fX6gOcsdQGtqKql
=nbOs
-END PGP SIGNATURE-


-- 
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers

Re: [HACKERS] One question about security label command

[Joe Conway]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

On 08/25/2015 01:02 PM, Stephen Frost wrote:
 * Adam Brightwell (adam.brightw...@crunchydatasolutions.com)
 wrote:
 So what about the buildfarm animal that was offered for this?
 We still have this module completely uncovered in the buildfarm
 ...
 
 I believe that is in the works and should be made available
 soon.
 
 Right, Joe commented on the 'open commitfest items' thread that
 he's working on getting it set up (actually, more than one; aiui
 he's building both a RHEL 6 one and a RHEL 7 one).

Yeah, I'm working on it. I also have reviewed and tested the patch on
rhel7.1 and am working on rhel6.7.

Joe

- -- 
Crunchy Data - http://crunchydata.com
PostgreSQL Support for Secure Enterprises
Consulting, Training,  Open Source Development
-BEGIN PGP SIGNATURE-
Version: GnuPG v2.0.22 (GNU/Linux)

iQIcBAEBAgAGBQJV3N3cAAoJEDfy90M199hl+8cP/iczkjAmz9J87/+wUfXDWj5C
rRCa4K9gxngU96u7LZeiufaAIj5Y84jJZlV+L9mpt2eHmWyxAbIUBGEt7bk0aN3u
tXsSBNXbtl3iTDK2QsZTBXiAUbXBKjSjpjyPRNggnpbPK8nEEgUTlV/WQmU5pgWc
V1fODx89tDROM5hhGxy6l4Q6bFnJaLSoVnnUT/+yJiZIyeN0TfzL+ekRdoyyrQYL
WR8bOPG2AVAHJH2saFDwJ8FbeohOgs87gW5U0eO40oGz21TJzsHMcdJRLYa8B650
6eJH1pV2YKhqSaeUjCqNOpie3EFBDlNmWmO92BhVC3oTDWxRLtObeoq9BB/B8tEz
XCy+to/aLB/d+Bntmkg5SoV7ODHLQdH6qHaXcemallNCz4/uTP9Cm8oDPL6eu7bj
AOeMx5cYDpvIKMjSRBsAEMxAfepc1VgAfxdthOBoYcswKXz1c3BIn3SjQnNQk78R
vhg4walAKGXT+dOfROdOaUcNUODpf18M2CPTAYm8M+uC/vcb+7j8MlRc+0xIz/LA
0iNLQAjdWDsSwiRqrt+GfV4peoSqwJenyGRhdOeRES33U+pT6kWWxSYy43cgLlso
GcT49DwSWDxwjU+9EtA2Rdxa/yBCAcrDQOwT2N/FQr2QQUB8WFfbAIq2G8fUl2q5
ZjAChs3KMSuWQJoVuwMN
=RVIH
-END PGP SIGNATURE-


-- 
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers

Re: [HACKERS] One question about security label command

[Joe Conway]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

On 08/25/2015 02:27 PM, Joe Conway wrote:
 On 08/25/2015 01:02 PM, Stephen Frost wrote:
 * Adam Brightwell (adam.brightw...@crunchydatasolutions.com) 
 wrote:
 So what about the buildfarm animal that was offered for
 this? We still have this module completely uncovered in the
 buildfarm ...
 
 I believe that is in the works and should be made available 
 soon.
 
 Right, Joe commented on the 'open commitfest items' thread that 
 he's working on getting it set up (actually, more than one; aiui 
 he's building both a RHEL 6 one and a RHEL 7 one).
 
 Yeah, I'm working on it. I also have reviewed and tested the patch
 on rhel7.1 and am working on rhel6.7.

I'm arriving late to this party, so maybe everyone else already knows
this, but apparently sepgsql is not compatible with the version of
selinux available on RHEL 6.x. So there doesn't seem to be much reason
for a RHEL 6.x buildfarm animal just for sepgsql testing as it will
always fail ;-)

As I have never before set up a build farm animal, and since sepgsql
cannot be run directly with `make installcheck`, nor can sepgsql be
installed in the usual manner, this may not be a slam dunk...

Joe

- -- 
Crunchy Data - http://crunchydata.com
PostgreSQL Support for Secure Enterprises
Consulting, Training,  Open Source Development
-BEGIN PGP SIGNATURE-
Version: GnuPG v2.0.22 (GNU/Linux)

iQIcBAEBAgAGBQJV3RB4AAoJEDfy90M199hlsg0P/2cPCkqbDpOzFLQzUi/MvgMs
CORS98FiAy/PYYhFBs75XJo39uSOX7nzk9M/tAAfFgjvV1jl8QUW0kFvBKE3P8bI
M93ZUT3tSG51cpfhj+Gaj6uvC3c7GVOj14vhvXOS+Mg8qaGfoa1kzJi4ku4Ajt/H
UurJWq529sTTETgGdpaMJgW1bLfseRJFjTN60FZI3DSUQZgQ6WuqIJ6tk8XhS0Sk
r6iTCeS3Z6QsiM3g20UIjLXfc+1Ju6AiZZbG4zeRkt6T5FlgofCS+3tDGF3Lnr0Q
ZGG5J9F5cpX+xEX7gNmWaPFvnb+PyLiqPDGMLFEWqrs6ST/IKT6TI2z8C6+PKmBX
t8wrDu3vZSGlWwosg3iN3UbzQcH2omuPbpZwiBf+fCMVpmp9IBr/itwL7rShI9Wp
NHAoU3o3f+Skgt/D/QEgGhGcjb7toftKxJcrhtnoDrCSXMd2XH7YxMbRamSIcQNq
Ih/lGfGNNdfJjcS3upnsgQuEnIHzqxIA2R8BprEz5E3LNTWQ74pe74UXOxvhLIfc
H9bXHeRZebvukue0GOO9HbArrAFB6FxsHgYtipY1o5VAxBTuQIvWv+tDXZnrPjud
Kce/eHEK6JLsIkuHmKYU4hsZPMIQYSBqv6z8aFHJa9bEaMrv6eQ4VvZ9DL+Xt7z5
9iRVlEUnOZ1FD7jebJTh
=+kmo
-END PGP SIGNATURE-


-- 
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers

Re: [HACKERS] pg_controldata output alignment regression

[Joe Conway]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

On 08/25/2015 12:41 PM, Alvaro Herrera wrote:
 Joe Conway wrote:
 On 08/25/2015 11:28 AM, Alvaro Herrera wrote:
 Joe Conway wrote:
 
 Does anyone out there object to a non-backward compatible
 change to pg_controldata output?
 
 I don't (and thanks for taking care of it), but as I recall, 
 pg_upgrade reads and interprets pg_controldata output so it
 may need adjustment too.
 
 Thanks for the heads up. There are lots of controldata items 
 pg_upgrade is interested in, but AFAICS none of these are
 included. Now maybe they should be, but they are not currently
 referenced.
 
 Well, if there's no compatibility hit then I don't think it's
 worth worrying about.

Committed and pushed to HEAD and 9.5

Joe

- -- 
Crunchy Data - http://crunchydata.com
PostgreSQL Support for Secure Enterprises
Consulting, Training,  Open Source Development
-BEGIN PGP SIGNATURE-
Version: GnuPG v2.0.22 (GNU/Linux)

iQIcBAEBAgAGBQJV3RrPAAoJEDfy90M199hlL+AQAJIChfxiDf08OqclgAHAcVr4
j5RKou1aeDJSHfDOoH4+f9wd8jaQawVzk/7pEy8aiumF4nioGcNcgVnG7w4qgHvf
vt7w41YZStd08fvwuXr37lr1sMnPQLWGwWFx5VecTgXPveLSdh8sWZyxrXBoL7Z3
2lJx8RByjyDYB/wj2Ci0MRtk2s8vapFkHDwHPKvmx/i0neMgbqaXu0WKTLaNfOUy
IIK1G5o0VHK4Qes3omtzfyTGLC299o1zfhW1Klk3uPukWliYiAjJfw1L8vAwLl0F
MFJZb+EaLKl5EbQMRPSPCyHN/XxbEgmuTNFvAqhbUDYmOOPOgBLbIg8ke/w0s0g2
fEpzDFGKmsiSdYj17BZ6jp+xafIGaN8+seWcTyNaMDrqG9WEGx3AkcBUxgXfForY
LyCOuZn1aS6hgQvVH5uiGg0QIHN0ZmzFBOTYUE+tUPetnQskC94IUT1rFRm1XH9I
T/+JD/EYEoRiosZyeFfx+Zf+caL9KmtrUutGP7OXuNBBNyiTq26QifDZjfG5Fd8b
IIxgeZQ3u0vWeTDuP148QrtioSj/IToUKhmn/kZvMwq6XxHhErA8Sc5zgzTE0dIi
X4cYRcFESmCzEoDtAASaulpDIxSMVMp5GPWumCyK8CPHIqq7c8lNNqfM2ljdrGjR
1tfHRhq8/BFPrjT1fcrR
=WaIR
-END PGP SIGNATURE-


-- 
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers

Re: [HACKERS] One question about security label command

[Joe Conway]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

On 08/25/2015 06:03 PM, Joe Conway wrote:
 I'm arriving late to this party, so maybe everyone else already
 knows this, but apparently sepgsql is not compatible with the
 version of selinux available on RHEL 6.x. So there doesn't seem to
 be much reason for a RHEL 6.x buildfarm animal just for sepgsql
 testing as it will always fail ;-)

Just to be clear, I have marked this on the commitfest app as ready
for commit, and plan to commit it soon. Figuring out the buildfarm
animal will be my next task after that.

Joe

- -- 
Crunchy Data - http://crunchydata.com
PostgreSQL Support for Secure Enterprises
Consulting, Training,  Open Source Development
-BEGIN PGP SIGNATURE-
Version: GnuPG v2.0.22 (GNU/Linux)

iQIcBAEBAgAGBQJV3RxQAAoJEDfy90M199hlkHQP/AtzBbKFxCFuNBKr/nTpvSOx
Sb2N0SdQINA/VbXYIS5yN4R4rUi33ZmCcDfQNs690X0feB2BF4cWpw2xHKyQSXZa
B2oxScwtW+ReiADIILjrfv14tK4IAq6lWDVlLD7f+yAwvpjMNPb4S7+qcFoDnP2A
weGlhpaQETpWqLMmM89QG3HN62hQeoSt1Zv9NiFDMyDso63jW/hgFELL8PFUeLtv
49tEI/ClaKLldLdu7uMJOouU9bsrxJzsnDRI4yf9tNotuzCjd9RW2P/CBVQMP1EV
YWfhxY8hxonEg1NLFc4Wvj5xkQuRpTyMPQnZQoHfQaLPM7Qfvi1oqn4xRBKMpi5u
gK/9B3w2oUO9CZAWM7HPnLgULZv+MXuUD3rYhVIlq4fPlgaD6lkHE1sbVC4W38jz
L9gyDycOSkaMU+FDtRSrH0TwSoMgtybMDdTRTxddVxDFIeh8f15rJISpPq1xmsAZ
pE71SVOf88Lo2TXliwh1sEeN7bZO/Hc/eUefKC4UVWgV/FbEnpQBT9U7qRuZBNIM
+mr9FKtdX/Gp0NzWLQRozS+lQJhG0j6iM3DG6kTPlqh7sqfcxgqbwQpnjudIRILE
89FrkwXfEX0OziW8h54fdmYakTlQqH9sPt8XG9i1lOmHRNtnQCnTuit4sLr/rkko
v9tq3xliqP3TtQXeRssY
=MxPX
-END PGP SIGNATURE-


-- 
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers

Re: [HACKERS] exposing pg_controldata and pg_config as functions

[Joe Conway]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

On 08/24/2015 06:50 AM, Tom Lane wrote:
 Andrew Dunstan and...@dunslane.net writes:
 On 08/23/2015 08:58 PM, Michael Paquier wrote:
 I think that's a good thing to have, now I have concerns about
 making this data readable for non-superusers. Cloud deployments
 of Postgres are logically going to block the access of this
 view.
 
 I don't think it exposes any information of great security
 value.
 
 We just had that kerfuffle about whether WAL compression posed a
 security risk; doesn't that imply that at least the data relevant
 to WAL position has to be unreadable by non-superusers?

So pg_config might be fully unrestricted, but pg_controldata might
need certain rows filtered based on superuser status? Do you think
those rows should be present but redacted, or completely filtered out?

Joe
- -- 
Crunchy Data - http://crunchydata.com
PostgreSQL Support for Secure Enterprises
Consulting, Training,  Open Source Development
-BEGIN PGP SIGNATURE-
Version: GnuPG v2.0.22 (GNU/Linux)

iQIcBAEBAgAGBQJV2z3SAAoJEDfy90M199hlgmwP/iPI4gJAM00b1mWiPHYSEMjQ
pdVgPkFgfGQKyTizo7rEv1nJTQI3J9aUD7hvqYvPGlSOum0xei17fiRUIKnfqGgZ
7aSuhc97gZ7U5LvDsClovEUDEon+RIibZAYHKnKv2qYDwO/ZvfdFFQNi9TV0eREi
QrEYafNo3/PWqJtrJoqhXaXyXsZ33FKtaaesQZJXvUUkTaE42eviq0cPiz2lHEsq
szlGBnPkBS3qthAusApetAobZH9OymL4yl1BWwmBl3d2nEvQ4OVFGWo195It4XyQ
98bMzXse0PvBuKkcKrlTjxPdtR9UE/2FHojh7VLaj+JQeCGjehXNuogGPr7XHNSu
cbCvIWsxW7Vz1liwFxY9I7Aui6/4X/oPehrct4CqaihqoztP1JrkQpVJDBYWwAhH
Q/sRe8gUY8AWQHQljt9nuZvXmEYBnFbSf8tWVZ3/yhU1fK9dcl9B5doIHwKQXXtW
+BHx4mOX5gcSRvGQFkJO0auE3Y9dvfUtpV4xDC57OHekgKA+rZw/HtElwKIhgrHI
QoCd9PpJdG3UngX7ffsRuhJIhTUCSOKA2AIdceRyH4UgtqtHLzSU1tom3XMcQD+f
mJvlKMwSvqh2Qmd/ZiNhgN4APkGk1AmH26hMMhI9HIrAIghkmPDfssLxYcBgJyDd
lt8dJLQDnaddFLuvdQww
=KZVU
-END PGP SIGNATURE-


-- 
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers

Re: [HACKERS] exposing pg_controldata and pg_config as functions

[Joe Conway]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

On 08/24/2015 04:38 AM, Andrew Dunstan wrote:
 On 08/23/2015 08:58 PM, Michael Paquier wrote:
 + Datum pg_config(PG_FUNCTION_ARGS); + +
 PG_FUNCTION_INFO_V1(pg_config);
 
 The declaration of the function is not needed,
 PG_FUNCTION_INFO_V1 takes care of it.
 
 Umm, we shouldn't be using PG_FUNCTION_INFO_V1 in backend code at
 all, IIRC.

Right -- those lines are a cut-n-pasteo from the original pg_config as
an extension code. Will fix.

Thanks,

Joe

- -- 
Crunchy Data - http://crunchydata.com
PostgreSQL Support for Secure Enterprises
Consulting, Training,  Open Source Development
-BEGIN PGP SIGNATURE-
Version: GnuPG v2.0.22 (GNU/Linux)

iQIcBAEBAgAGBQJV20DqAAoJEDfy90M199hlA9wP/RtnahsLzmbsXfPssTGUfdHu
nuiF5Sgpqn5/tMNakNVr/ACBiSZQeFUf3FQNRzyoOK6zMXCox4HbSFKi4u0UxpYV
CZZgIKByf4xaHjaZGpnY5dTteBQXdRv3Dp85hhmVbDHbO80+7e7zf0BI5QrUm14E
Nhv6PJn6NMBm/GJrvm76+lDt7DJWYygi/3Jupn/aQNpPCZ5bHP+e4e/NC2FMtW3y
Knm+KN5YEA0IWZKnM0s9kIfYeI9PE2tsF3jpdw8U7BTzziLf/6yTVXlJ/5xj0CfU
1kubgcZTp5UhDOWD7RuRQ6WUzbye/Yd/+9C9SNYltidZY7tnlbRyb0J6QerXNakM
tM+eXAbroXnfAZulq8YJO8nFPviXh6Y4F1pEXtpVJIuLTu9NXEDhRLPAzsSXciCa
yQuq98L2UmzpSr9i5ETMmjb7mUPcS9/IR/FQldNgP1/ARY2CTyL6hbdCJH8QieVo
plEUaYPz4QbKTyF/OZsuamDSpqun412Zs/LRgF5kQhIcI1Q0z9SJ4GwQUZb/bwQm
c0ztQnW8AKtzBgGVCYoJSKd4bD5w/Qtv8WdoZJzXnu3GOvq/laS+kCaBcYl3N7Rf
dwDKpYmWitmyIT0THzhdCiJ38rMgq/JjmhCJQiMJJxvvsadl/mPKUO6k4ZUMNw6O
BKrHf/JETN/Wnqd1IPqq
=ohKC
-END PGP SIGNATURE-


-- 
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers

[HACKERS] pg_controldata output alignment regression

[Joe Conway]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

Do we care that as of 9.5 pg_controldata output is not 100% aligned
anymore? The culprit is:

  Current track_commit_timestamp setting: off

Its value is shifted 2 characters to the right with respect to all the
others. I think it ought to be fixed but thought I'd get opinions first.

Joe

- -- 
Crunchy Data - http://crunchydata.com
PostgreSQL Support for Secure Enterprises
Consulting, Training,  Open Source Development
-BEGIN PGP SIGNATURE-
Version: GnuPG v2.0.22 (GNU/Linux)

iQIcBAEBAgAGBQJV28z9AAoJEDfy90M199hlFUkP/3prO8QakKsHG4+kDu2td2Oj
ITkOTm0fE67BxalHr2UkkH5kMrcbFaXsluzPbuCHW/i3VMemPiRaQmexpgoD7NUG
qAmMv5BNSYaU02iRp9Ay32g9Ohoh/OrZfD8MNCWyvTmxVB730I1bhRxl308S+Y3J
gqiy+qufVuTa4O65N2+5xGSUXpP352kL+/m6+xprb4LY7gaVpAoxd3wFrSj6A6O5
MJvOTHSoM67A8UXuCs2PVzyhb9U+egJ5IaAI7ItMgx7L+83ZziHEumqe3VYI+AW8
+vL5FtCl09rpE56npgG+2LxGSN/yhdiYOrSN3FqCG/UuuXKwwXnEv70i+71/NpAO
Ychb/5c8pmo7dZFR6H6mbtWYDjdaGurtCwe2uEG9C41cXDpztYZHePMgFwCAKwdm
syHGeWN9YWfKq8US2NkOiGcU2pTzoc6aQeU1U0lJSjEwCzn2d7aTTUJUxIHkLgcg
54GQ+qVbi4N+mmJ1ME39gK1tJObp4bEOGz1ZEryACi+xnneyfncxdP8lRaYwCkWS
YkYLAi+Ojic/20Eha/d4DuWLMjsNUgfBY2InsT8R1bmMDRInfuEaffclrQrk662x
GggmRkrJ0AQzLn+T8zo9N8G9veWeLy7He0gz2LtNCQzDKEIJ68FeIC/ZltJ14PF+
9WivdTJa5W3pkAohatKF
=Ax9S
-END PGP SIGNATURE-


-- 
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers

Re: [HACKERS] exposing pg_controldata and pg_config as functions

[Joe Conway]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

On 08/20/2015 07:54 AM, Joe Conway wrote:
 On 08/20/2015 06:59 AM, Andrew Dunstan wrote:
 I was a bit interested in pg_config information, for this reason:
 I had a report of someone who had configured using --with-libxml
 but the xml tests actually returned the results that are expected
 without xml being configured. The regression tests thus passed,
 but should not have. It occurred to me that if we had a test
 like
 
 select pg_config('configure') ~ '--with-libxml' as has_xml;
 
 in the xml tests then this failure mode would be detected.
 
 I've found use for them both in the past. A fair amount of bit-rot
 has set it no doubt, and these were quick and dirty to begin with,
 but I have these hacks from a while back:
 
 https://github.com/jconway/pg_config

The attached implements pg_config as a backend SRF and a matching
system view. A few notes:

1) The syntax is a bit different than what Andrew proposed:

8
select setting ~ '--with-libxml' as has_xml
from pg_config
where name = 'CONFIGURE';
 has_xml
- -
 t
(1 row)
8

In particular note that the name values are all upper case to be
consistent with pg_config, and at least currently there is no version
of the function which accepts a name as an argument (didn't seem
worthwhile to me).

2) No docs or related regression test yet. I will do that if there is
enough interest in this getting committed. So far no one except Andrew
and I have chimed in.

3) Requires a catalog version bump (not in posted diff)

4) The static function cleanup_path() was borrowed from

src/bin/pg_config/pg_config.c

It is a small and stable function (no change since 2010 AFAICS), so
maybe not worth the effort, but I was wondering if it should be moved
to src/common somewhere and shared.

I will add this to the next commitfest. Comments/feedback encouraged.

Joe

- -- 
Crunchy Data - http://crunchydata.com
PostgreSQL Support for Secure Enterprises
Consulting, Training,  Open Source Development
-BEGIN PGP SIGNATURE-
Version: GnuPG v2.0.22 (GNU/Linux)

iQIcBAEBAgAGBQJV2PykAAoJEDfy90M199hlQW0P/1fLCtFe50wFanleOxo41aki
yR8uG5vUZCLosx7lYd4+LyeE2g+bfs+fK6XgL1qIafI0zyxQSAU8TtjsIPQjjsvU
rNn1MWRrlOLEfOMMzbJPo01w5wzLhBvFzrYQ8vVtvf+T2PzjbU1hTMOcmaeXv6If
jYv0KQDgPBk/VPZ0D7MI4nYXVzNSInDLD7TGEpoTQwZ0oqvZwScSXc933isoULB4
4isael+g6mQJNoPz+OQEhUSoC922mrGs12SarfHJiUqJs1/NleClRRZ/9llCBnb2
3+zW6cb4XNh8aVP33zTtCsbrio206VjumWUYMNs546+qChormBOnYtZiIVRNRnPk
z4x/vxuhXVndDp1VnE5V5mRiW3B8ABliBf1Bcnf/Z+Gxi84LaZVtmL2hJrmn7voT
EZsQn/gmpB6ThHKbOl3t060fGZ/RAPDUwOWoYUIVcohOQqxK/iIka0bFM5cnuXO0
8oJ7CFkPSW7kBPs3uPO4Psf/jzrfaK3b/ZfitoV77sMQiVCABlR3a8khw+cPBrok
av/1afnGfz6qSxsV8sAyKUmRZkLDtmT01GUHCuujof1PQ3tD8zVsQWI3r51UcGB3
tFKvvy9koTHEunqkU6yQrCWNOEzHpGXEa1RIV33Ywgh0deKVEU5EbfJF5iIHBgOy
dYf2PHbYW7F1RSqKnZIa
=A2+X
-END PGP SIGNATURE-
diff --git a/src/backend/catalog/system_views.sql b/src/backend/catalog/system_views.sql
index ccc030f..0d2e8f1 100644
*** a/src/backend/catalog/system_views.sql
--- b/src/backend/catalog/system_views.sql
*** CREATE VIEW pg_timezone_abbrevs AS
*** 425,430 
--- 425,433 
  CREATE VIEW pg_timezone_names AS
  SELECT * FROM pg_timezone_names();
  
+ CREATE VIEW pg_config AS
+ SELECT * FROM pg_config();
+ 
  -- Statistics views
  
  CREATE VIEW pg_stat_all_tables AS
diff --git a/src/backend/utils/misc/Makefile b/src/backend/utils/misc/Makefile
index 7889101..49c6f08 100644
*** a/src/backend/utils/misc/Makefile
--- b/src/backend/utils/misc/Makefile
*** include $(top_builddir)/src/Makefile.glo
*** 14,20 
  
  override CPPFLAGS := -I. -I$(srcdir) $(CPPFLAGS)
  
! OBJS = guc.o help_config.o pg_rusage.o ps_status.o rls.o \
 sampling.o superuser.o timeout.o tzparser.o
  
  # This location might depend on the installation directories. Therefore
--- 14,33 
  
  override CPPFLAGS := -I. -I$(srcdir) $(CPPFLAGS)
  
! # don't include subdirectory-path-dependent -I and -L switches
! STD_CPPFLAGS := $(filter-out -I$(top_srcdir)/src/include -I$(top_builddir)/src/include,$(CPPFLAGS))
! STD_LDFLAGS := $(filter-out -L$(top_builddir)/src/port,$(LDFLAGS))
! override CPPFLAGS += -DVAL_CONFIGURE=\$(configure_args)\
! override CPPFLAGS += -DVAL_CC=\$(CC)\
! override CPPFLAGS += -DVAL_CPPFLAGS=\$(STD_CPPFLAGS)\
! override CPPFLAGS += -DVAL_CFLAGS=\$(CFLAGS)\
! override CPPFLAGS += -DVAL_CFLAGS_SL=\$(CFLAGS_SL)\
! override CPPFLAGS += -DVAL_LDFLAGS=\$(STD_LDFLAGS)\
! override CPPFLAGS += -DVAL_LDFLAGS_EX=\$(LDFLAGS_EX)\
! override CPPFLAGS += -DVAL_LDFLAGS_SL=\$(LDFLAGS_SL)\
! override CPPFLAGS += -DVAL_LIBS=\$(LIBS)\
! 
! OBJS = guc.o help_config.o pg_config.o pg_rusage.o ps_status.o rls.o \
 sampling.o superuser.o timeout.o tzparser.o
  
  # This location might depend on the installation directories. Therefore
diff --git a/src/backend/utils/misc/pg_config.c b/src/backend/utils/misc/pg_config.c
index ...aa3349d .
*** a/src/backend/utils/misc

Re: [HACKERS] exposing pg_controldata and pg_config as functions

[Joe Conway]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

On 08/20/2015 06:59 AM, Andrew Dunstan wrote:
 Is there any significant interest in either of these?
 
 Josh Berkus tells me that he would like pg_controldata information,
 and I was a bit interested in pg_config information, for this
 reason: I had a report of someone who had configured using
 --with-libxml but the xml tests actually returned the results that
 are expected without xml being configured. The regression tests
 thus passed, but should not have. It occurred to me that if we had
 a test like
 
 select pg_config('configure') ~ '--with-libxml' as has_xml;
 
 in the xml tests then this failure mode would be detected.

I've found use for them both in the past. A fair amount of bit-rot has
set it no doubt, and these were quick and dirty to begin with, but I
have these hacks from a while back:

https://github.com/jconway/pg_config
https://github.com/jconway/pg_controldata

- -- 
Crunchy Data - http://crunchydata.com
PostgreSQL Support for Secure Enterprises
Consulting, Training,  Open Source Development
-BEGIN PGP SIGNATURE-
Version: GnuPG v2.0.22 (GNU/Linux)

iQIcBAEBAgAGBQJV1epAAAoJEDfy90M199hlDjkP/AjAMtF4Q4rwfy5CsqA1rCgX
E/hLoTxExwU11nS2Q6IxC1unsXCDQrr2lkutKsw5Ybo78O7pMvR39GqShQ6ItaOr
xLxkYmxU1pEC4MAzZ6TR7RCAiP5SOgDEC3X6ArBqc0zub6FrnuYI3zv8eIgcTWqT
cFan4vCHYZnWUp3KQ0sOpSl4I/5jeW3AwrfTlnwskC8NwpP0Oa0DiXXTtXoRUYZI
CaWUsV9FgfzGvhyQCJpwcldEU9TprU24U09CpIVzSmw6Q9eQBHO4k+nT/Xw3BRjH
LxPM7gH9LweQOJhzP3J8agrJqbnSntayPZKG9ZsqMvC/8Ly+mlIO/X4cuEYpKO94
De9jO+aly6NhUdCpOdM6cZdqsTggXExaafl61wazYBUcLWotBnL9I1E9n59fm+yu
wgec7vdWIzZn6FYr+Ox2sgOBbxXVs3l/FLTCkoUgsZWRvlEL/naePr5TxMJMyqpo
pt15r1WRd4KwDEN4qxYHrzOab/T7QG1RS9Qr2v0GMPvQp4lIXgCq2aJJXy+iCDPE
lifDpHipk39h0r0RN377UFmfW3Z8DNLj0UQpuw+bOXtFLZpcA4WQdg64qXBaUU26
7icScC7+PpEr+HialFyA8lbDb9EVRrUaJ6CJajrGy8iuH/vpME2+40sgFTvavZtk
a0mfnPIdWJjzkldZGZ23
=hbBg
-END PGP SIGNATURE-


-- 
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers

Re: [HACKERS] [patch] A \pivot command for psql

[Joe Conway]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

On 08/10/2015 04:03 PM, David Fetter wrote:
 I am wrong on that? I feel like you guys are all telling me that 
 \pivot should happen on the server, but the point that it would
 not be realistic to begin with is not considered.
 
 I think that starting the conversation again, especially at this
 stage of the 9.6 cycle, is a very good thing, whatever its
 outcome.

Talk to Atri Sharma -- he recently indicated to me that he might be
working on built-in pivot in the near term future (if not already
started).

- -- 
Joe Conway
Crunchy Data
Enterprise PostgreSQL
http://crunchydata.com
-BEGIN PGP SIGNATURE-
Version: GnuPG v2.0.22 (GNU/Linux)

iQIcBAEBAgAGBQJVyUVSAAoJEDfy90M199hlhEgP/1mQpZ0JOR2kbaP5Iw6FY4q+
P1SLWbCWMhVDp97OAjbP0T34YmG5Rw0fDh4WLPbNBp6xyPTQQgIVFvQAu6kDSngk
X9kbQHKGE+pNqc9hMc7CyuSse8Pw8VeQGRDU5a+8E3fPdi9rbB2YTDt7SJIXlavc
zJ8kZlUj59Xw9Kdkpon8Jb/Nxn3JV4GWLTe4+nxRZoH/9POjslyM+rVGtrMlHA59
0NWWPnTsLfU1HNk+olf72ihZpmQM4KPog8PdWo0GyFqJhMwmYtE/WTJh4jNDygBe
NXTQE7/I5OA6fYQniq+7Wsyhc5raOH16lVSSo0QquuTtGG2mrYsvd82Zx7J0SDQp
NfVk4qgjJYMNBN9/hvPXZZ2+LReYqliloR2PqLqxgDn3DyGgSpSUs1JyDZRtoJEj
P4jEVGVWnUbjKuNldRJZi1DmMTKVSS2RSnoC0RJ7DzAfUyQ4oH4FmX8jX5rZpoXN
nJLtVPhIRpp0A2Lq849hXB3/LuNzjYmZ3VvGNUwffTD7d3XxQ/Zeb9ZtWZszfJUo
zjMAh0wFwDtdVBYdFStzlByGTSEIqeqdGCDSHhiZlNw/E0xV2YjNzdUP9N34aWml
i+KUgPMxTJ/GAineSXpjt+I6Y+cHA10JpQLOf6fVdrOp/R1Z2EqFfZl2GzbyXJ5n
lz4QjhOfx6YG1Tdi5qYW
=nyuc
-END PGP SIGNATURE-


-- 
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers

Re: [HACKERS] [patch] A \pivot command for psql

[Joe Conway]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

On 08/09/2015 10:37 AM, Tom Lane wrote:
 I can see the value of a feature like this, but doing it in psql
 sure seems like the wrong place.  It would be unavailable to
 anything except interactive use.
 
 Is there a way to implement pivoting as a set-returning function?

That's exactly what crosstab() in the tablefunc contrib module is.
I've heard rumblings of someone looking to build crosstab/pivot into
the core grammar, but have not yet seen any patches...

Joe

- -- 
Joe Conway
Crunchy Data
Enterprise PostgreSQL
http://crunchydata.com
-BEGIN PGP SIGNATURE-
Version: GnuPG v2.0.22 (GNU/Linux)

iQIcBAEBAgAGBQJVx6b7AAoJEDfy90M199hlOJYP/3WJTFrB22SlC7pxTFl/L8La
9F0DbNlCyyK/oUkYH+dy5MXBnwHTFAwj2sEik7xNhax7aPIMnXh095f0AaMjouVU
S0J0dGb5quYYK+TUWBBL745nRIl786H2/XbZbP+L7pz2W72ITtTbKqMHpXVyzMiF
DfEN9xnCd05MF0WiaAXtwtz8HXQkFJxD/r5kgmHvwMIBPvvzrAg6CwHh/8kQMlY2
1kvkYnKvFSNp+PrZ0CvANs6ZyqaDJN1w7nsXul7HAWu+KhBkHxAilnBkCjjOT5JD
beF8E1KNo60k+3zjphEN1yKBl5tT7r9mYLhuOLuI0UdpNpdd8u+rSRTSFaIRMGQ7
UDQIXOtVHSlKSSOpXHH6FYvksUQMDVvPeSwKoI2imwAjSStkInHJMj6cs2uKxsZi
5P0sRnulx7Ur4M1mCq7t3+IKiaZ2KzO0WZ5ewJ1mMt5hIqD7QADjvDoPn0qozV5T
lX3pY4PUaL+N8XwlgBb69vGgUeG3N4nEvDSiUyLbFC3au/osczRGloYBq8AgDNuX
Dta9AOkzbNAA82ODUzFoFts8/1Ydu8vhwnpQiNcl772Hf0fpNvdFGtclc4K+2ToX
4k2WmezT5y8d6IdPPDqM92wbWXAOBIy1I+kaYnbnQpxn2QYzkKrPbJ2unTTKTdUa
5/uFA0fg37acwloBMux/
=5lhb
-END PGP SIGNATURE-


-- 
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers

Re: [HACKERS] WIP: SCRAM authentication

[Joe Conway]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

On 08/08/2015 06:27 AM, Robert Haas wrote:
 terminology.  I think we should store (1) your password, either 
 encrypted or unencrypted; and (2) the method used to encrypt it.
 And that's it.

A petty complaint, but it has always bothered me that we say the
password is encrypted when, at least currently, it is a simple hash
(cryptographic hash yes, but not encrypted, and not even an HMAC). I
think we should try to start using accurate terminology.

- -- 
Joe Conway
Crunchy Data
Enterprise PostgreSQL
http://crunchydata.com
-BEGIN PGP SIGNATURE-
Version: GnuPG v2.0.22 (GNU/Linux)

iQIcBAEBAgAGBQJVxhm7AAoJEDfy90M199hlWRsQAIPliVReOYRRD/BJaZlB9Vjs
4YDolZZD9zR2+VPNxG/VaGHJ68rXlnfU/P0GrIQrS67t1xgwPxbUW6TCBsXJDnIE
wo7i5mJn9yn+AowccFiZTToKK8oNjRd33OJ2q00lAGiuaksnBhcJjMCNUHqf1Oz2
rUA/YiTp7RHXOQfiAxSoMKytK2y+rnQA+rnvPiE7XLKYE9rZ5rLiGhV0MPaNOFms
aHZIcYX5Tl2I3RsCexLMMA1qM001wSTyoti7o9gL71EXLV6ea6xt10a++k6oJ19y
oU7WjwKgV2XOGlQNC3/rUEKvuAtQhTlJpx9Q6xmTYidN0QHkZDdpJUblGZoxR2Vz
lT2zZdcpDhENynFZ1nTsd+CNWsn5T5vTVgnuKpG5qIMgT+kSG2JeiS7h+RY4rRtk
bl08tZmQBUBu/3hrRxQVPrt1NISteKXem2OLGphIKQEOmu/Kf43msYHQ+1qY0FTB
TZ96tVJnYTjQZp2P0IdjMf0qpOzK8qkMx2Tb6WehMd9yD1DtxQyKmxGpvssgEmQ7
1n3L/HCKWXF0MbI8QefIsO70ft4hzib5V+G7YmF00dWQM7NhDZYf6ejn1WmCP26u
w9wOHQcCAAKPI2knh3k2Ngdynl8Gofkxr7Le+NW7TGM+bp2U5EStTEH0r70mzEIg
KvB4dWX+tlZowujUmFhL
=VDCN
-END PGP SIGNATURE-


-- 
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers

Re: [HACKERS] Draft Alpha 2 announcement

[Joe Conway]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

On 08/05/2015 10:15 AM, Josh Berkus wrote:
 * Make pg_dump work back up Row Level Security policies

There were far more than this single bugfix related to RLS. You might
want to say something like:

* Numerous Row Level Security related bug fixes

- -- 
Joe Conway
Crunchy Data
Enterprise PostgreSQL
http://crunchydata.com
-BEGIN PGP SIGNATURE-
Version: GnuPG v2.0.22 (GNU/Linux)

iQIcBAEBAgAGBQJVwkf1AAoJEDfy90M199hlEnwP/RNObNwpdzN9MxWTEzLQfB5o
PdQ4kjE4tY/PdYrLv2G7a12G9i/Lfkza1grHc+FaAuc7QPToOPLEut/punZgPlU2
+Zf9Bn1Pjkl9h37BbW1H978qAq6vbS4R+9mp8qamMKfmYlJptCSOrG549wTqOesM
640ZfFsnB/3L0ApIcfrg/EYZPrl/Ue9PntFK1cKwcu9BAPC+Sc/kM5P/nxyz2Avo
Ovetv1AUlSWTLARDBDyXDiCaB9ADWLrlPvfNIt6DuzkEKADzh8R49YLCOkhdWW+a
z9LYqINtlRfwN9oh7ob/OJD3FT1SPjHOiBwQB8bGJGSAqeMSTY5owuBZOnDlcZx5
cK7CFUQioIY831o5z/nyLdzYR/LRzn9tr4yLoVIDB0ZERdBtu7xI2pM3S2TB9yJk
U2PySM2LFTBLlXTI1al38/yKVZCK+aLcF3jqZxEbEOE5SsaudoDQUcrR3MeSSwoy
bnUYDez4sLa96j4seF0yiRSlYYUZFxE/BW+VW8QF0e9l8JX0WWoZCTMC7m28eUMN
HMa5skbQrE40taJt1kbNz9FGR8u5EeF2cbe5A9ys7dvijDqt1fEYLNQCY4FZ3g3/
yPFip0txcL2kJ8qGUILxWn4dGeNXQTcBQg1L41ZkOEmTW+oEVvUZ0P2TtRBYXKG1
2+cebmtLgaO8O3cY4O+7
=9lWg
-END PGP SIGNATURE-


-- 
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers

Re: [HACKERS] 64-bit XIDs again

[Joe Conway]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

On 07/30/2015 07:14 AM, Simon Riggs wrote:
 On 30 July 2015 at 14:26, Alexander Korotkov
 a.korot...@postgrespro.ru
 
 Any thoughts? Do you think 64-bit XIDs worth it?
 
 The problem of freezing is painful, but not impossible, which is
 why we have held out so long.
 
 The problem of very long lived snapshots is coming closer at the
 same speed as freezing; there is no solution to that without 64-bit
 xids throughout whole infrastructure, or CSNs.
 
 The opportunity for us to have SQL Standard historical databases
 becomes possible with 64-bit xids, or CSNs. That is a high value
 goal.
 
 I personally now think we should thoroughly investigate 64-bit
 xids. I don't see this as mere debate, I see this as something that
 we can make a patch for and scientifically analyze the pros and
 cons through measurement.

+1

I've been thinking along similar lines to both of you for quite some
time now. I think at the least we should explore an initdb time option
- -- we can and should measure the pros and cons.


- -- 
Joe Conway
-BEGIN PGP SIGNATURE-
Version: GnuPG v2.0.22 (GNU/Linux)

iQIcBAEBAgAGBQJVujVzAAoJEDfy90M199hlphUP/j/+TEJO05h+aLD1TrddZ01f
Fq2ijyvQjfe3aBN/4DEKuVBPMsQ6ZWLWtYJ3/FpktlFUIoDdDWJY//8rb63KqUut
tiSMI4MNzIp/ImvyR1pMJpAmfF9zHsJOiC8Hjpj9J8ity1BXm5My0XYzf9cux/KN
Qr8e5RTiPNKZyCB7w5Ci9byYIQKwHS9UyoHhgXQhZTopYLqrN9G7KxjKHZjTYxAs
6uJowQqsoevlgi15L8Ojk+KuJuowEHhVthhZ0f147twrOu2PwvhPP0/tf3TCSzKW
I3TGC8ChQ67+h/x4lF2LMENvDwGZFh0fB4foeu0F3oR5YX4jG6pic/k7BJFPke3f
YPk8PnA4fn5PM2otgikExIM6NFm+1y4JEeVOcGaA0GungdbgcBuN4p8gLvO9zJRa
qsJp6U+FHK7m68jBVAlo0aVERikh29devypOSWhz474nvYsZIm9bfQ4te+DQECzw
m3a9KJWJUy7Bj8xkwLpMMXmm83bIbvNMj8oDlg9tMo//CEzSsXyNjGUPG0/U9jIs
YHZUYd24i8Wg4+BjdQ19ULJH22ROZa2JBq658t6n97vab7HS3ZWGPhao0piYW20i
/q8wmd52KE0e4gg4Jixc1p8kPvIItFeJliEPgbRC1+7vnZu0rkENxXpTuS/g1fn0
Ql/P9C7Nb97cux9EvlZv
=gX7d
-END PGP SIGNATURE-


-- 
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers

Re: [HACKERS] CREATE FUNCTION .. LEAKPROOF docs

[Joe Conway]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

On 07/29/2015 04:46 PM, Joe Conway wrote:
 On 06/14/2015 03:46 AM, Dean Rasheed wrote:
 I think the docs for the LEAKPROOF option in
 create_function.sgml ought to mention RLS as well as security
 barrier views. Also the current text is no longer strictly
 correct in light of commit 
 dcbf5948e12aa60b4d6ab65b6445897dfc971e01. Suggested rewording 
 attached.
 
 Any objections out there to this doc patch? It rings true and
 reads well to me. I'd like to check another item off the 9.5 Open
 Items list..

Pushed to HEAD and 9.5

Joe


-BEGIN PGP SIGNATURE-
Version: GnuPG v2.0.22 (GNU/Linux)

iQIcBAEBAgAGBQJVulxZAAoJEDfy90M199hlpL8P/0S5tpWTNNGpk4suaoWVhULX
bAopCCZJLyWS7uZ4/PqMZvV2iVTiQvKrSMsKwXQsvm0fod5V4nC7UwSp9vqw0oE1
o0rzUFpcE1ZeUwbec5S98WZ4wi9HONO51/A6/QYf3I5LlWQBIvU5/5g8DINxtIlp
xe60Ihr5K1QUEAOGDqYWhMAyMpQKm0hBjriIIzC/+SW1gr0bXqiQcSytqTi6HV+w
y8x/YByJtYZEWgRuuMK+Cd6V7xFfBgdMlFepk6vPsnOZi1m+NVYGxVLGR5fzBDan
BTunV7d+uTQfrzwNXR8BUrreU/ED0R55CaSNCQEF5vnERPjLuGaiWxZjSOqI/8GF
FLBLlCJAH9V+o2krBeM74aAp/JkI3y1F7I/3otrxH0nFjdw4fpKrEPPiG4esG5zv
Y2J66aFHlykc7rmjSAWDiJGY6wfvinmjkeRTYCyt8cBRdeXuKO3LrjxY/9ZX7R33
cfUhCsBczRwg/7v5uEniE5k3SQ+YS7xwfLz9VZUuYCKJyMx4nego/VGVtGfvlJ2d
BWjcfHgjRdFy1alfPWZNEdl9F/DoGtAoEpcpawydtMcQCn5g/kg1mfCqg2P97VXe
rcay37smjACFBsTghDd23ufa0eNCTOj0hf7Fb19Ecmcm8XQwlVW7sByPjg89qRKd
mAIR5yIP5g/ptz38R8RC
=LzHH
-END PGP SIGNATURE-


-- 
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers

Re: [HACKERS] [COMMITTERS] pgsql: Row-Level Security Policies (RLS)

[Joe Conway]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

On 07/30/2015 06:52 AM, Dean Rasheed wrote:
 On 30 July 2015 at 01:35, Joe Conway m...@joeconway.com wrote:
 On 06/01/2015 02:21 AM, Dean Rasheed wrote:
 While going through this, I spotted another issue --- in a DML 
 query with additional non-target relations, such as UPDATE t1
 .. FROM t2 .., the old code was checking the UPDATE policies of
 both t1 and t2, but really I think it ought to be checking the
 SELECT policies of t2 (in the same way as this query requires
 SELECT table permissions on t2, not UPDATE permissions). I've
 changed that and added new regression tests to test that
 change.
 
 I assume the entire refactoring patch needs a fair bit of work
 to rebase against current HEAD,
 
 Actually, there haven't been any conflicting changes so far, so a
 git rebase was able to automatically merge correctly -- new patch 
 attached, with some minor comment rewording (not affecting the
 bug-fix part).

Good to hear.

 Even so, I agree that it makes sense to apply the bug-fix
 separately, since it's not really anything to do with the
 refactoring.
 
 but I picked out the attached to address just the above issue.
 Does this look correct, and if so does it make sense to apply at
 least this part right now?
 
 Looks correct to me.

Thanks -- committed and pushed to HEAD and 9.5

- -- 
Joe Conway
-BEGIN PGP SIGNATURE-
Version: GnuPG v2.0.22 (GNU/Linux)

iQIcBAEBAgAGBQJVulOVAAoJEDfy90M199hlURUP/2TF7r77taLPhQtEk3CFFQEn
mrt90N4DJ43VwGwC7mfdBsKXoJ+3jF3Hpghw/7ulI731/Io7C514gYDDvwGkrJWu
vK3vzXEQu9CIIfh97CsJ5mmenaaxrF9ZSaWDbYvQQMwMnxUS5CGWwR6VSp+NhCZ9
cnfA7idbxNjfBsjG0nQvtSgV/HOp0tP3A6dlYPTXPiIzbT9IiOpxWPwoQYgMSTcP
TBgK5MHG5JWrK1Bcg3BlQzYZefKEwN+LGU6zal4P4AjM14FfyMKfMc9A6EP9vtRl
jFekmRUddbXxWddl0ZSSV5BY9BLTRL2CZFhMQNQ9xKDlsK1cuYORN4v+TgRCjPKy
PdMH2tgndWsNNRTmj/vWUJxMXnHARl8MmtY8pau5Z6PKNUcASqd5Xq+zfKxOw8vf
lS8c4eRsLcCD+TZ1rv5K6VULmwBViU0gKP6Xs62yDHsz/Zwvt2ar1fW/25peohhb
m4j8vOCsdik9DDcJf6dF8sbb/z0FVh+JQqWhjbSJYioX9BOw/1AoNbi44wS7HzV1
vdhWx6qGWZnxi5qtb9j8BU0eFr/Q65kU3hsp2smRA/IK0bCQaO08rDQlPYsIHq10
SFodULNKFzpGvkzQ2Yqv1oyJ6jMvLtWgr9vBUZvPo8OHUyAkR8kfrZyzWyr/L/Mm
6jcuFNdYSS5F7W/S7ost
=GJw9
-END PGP SIGNATURE-


-- 
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers

Re: [HACKERS] dblink: add polymorphic functions.

[Joe Conway]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

On 07/29/2015 08:56 AM, Corey Huinker wrote:
 On Wed, Jul 29, 2015 at 10:48 AM, Tom Lane t...@sss.pgh.pa.us Not
 sure why inserting a variable name is so much better than inserting
 a type name?

 In a polymorphic function, I don't know the return type. It's
 whatever type was specified on the function call.
 
 Say I've written a function with a function like 
 outer_polymorphic_function(p_rowtype anyelement,p1 ,p2,p3, ...) 
 returns setof anyelement

Remind me where you get p_rowtype at runtime again? At some point you
are still having to calculate it, no?

- -- 
Joe Conway
-BEGIN PGP SIGNATURE-
Version: GnuPG v2.0.22 (GNU/Linux)

iQIcBAEBAgAGBQJVuPv8AAoJEDfy90M199hlYCwP/i0/berqnjXFch6zFM5TDZ6h
+UxQxMmVg933U6Cdoc+huMz8Hiotix76BZVgHOa8xI7Vktx1y5D7o7auczg31v4o
BkzbJFX9ziK5TXZm5wEvtTPNJOOq25AqvHzmrwr4JnPvyAOCKQASTqhIi95mdflZ
tGI+fuI4Dlkj76JaIuZjIh1rKMdycHsRmVfULVx6luR5LwzhX/iyW66pMkNHPYui
7K3DP2hF4HR6xoq4Jvj+HX1MSLLRAjm6+emx6YKnkSkxCQvL5EzwupWWhr7khrYk
QV0fwbAG5JtQJlid/DxezUFgpi2qs2AoPy2ub7JyEZjY0ULt4ehOx9/pzk0ATMNo
e3jB1H9BHTCiy5tY3VZBCe0uQ3lqiNalyUPcwYviS3yciuNg78rIkCQKe2KritZw
t0BY0SMASjbgIINlOLkDCg3HaYi3JujdbwSR5dG41RxaMej3MMieh3Opyg9bfZhI
TxWLsec7FPW/T23wPGk1aQZ7IbLRlOz95fJlAua6g1d5m6GWE3lyRQAQP+QFNWfX
/dmAy0Hvyp3a1wRsFrsG1W+GoyNV1pwfjXp+QlDDhGf8G/Q4l5s7OzZRcLs0O67Z
3K7Jn2k8ps4ZxA5yqRZdl3aAuaOpf3iqffQEeWQqXx7UAM5Sd8qorOJXpNhw+JtX
9W1YQ3eNgGkDfcOa9JLm
=P2ff
-END PGP SIGNATURE-


-- 
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers

Re: [HACKERS] more RLS oversights

[Joe Conway]

On 07/29/2015 02:41 AM, Dean Rasheed wrote:
 I don't think there is any point in adding the new function
 transformPolicyClause(), which is identical to transformWhereClause().
 You can just use transformWhereClause() with EXPR_KIND_POLICY. It's
 already used for lots of other expression kinds.

Yeah, I was debating that. Although I do think the name
transformWhereClause() is unfortunate. Maybe it ought to be renamed
transformBooleanExpr() or something similar?

 There are a couple of places in test_rls_hooks.c that also need updating.

Right -- thanks

 I think that check_agglevels_and_constraints() and
 transformWindowFuncCall() could be made to emit more targeted error
 messages for EXPR_KIND_POLICY, for example aggregate functions are
 not allowed in policy USING and WITH CHECK expressions.

ok

Thanks for the review.

Joe




-- 
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers

Re: [HACKERS] more RLS oversights

[Joe Conway]

On 07/29/2015 08:46 AM, Joe Conway wrote:
 On 07/29/2015 01:01 AM, Dean Rasheed wrote:
 The CreatePolicy() and AlterPolicy() changes look OK to me, but the
 RemovePolicyById() change looks to be unnecessary ---
 RemovePolicyById() is called only from doDeletion(), which in turned
 is called only from deleteOneObject(), which already invokes the drop
 hooks. So ISTM that RemovePolicyById() doesn't need to do anything,
 right?
 
 Seems correct. Will remove that change and commit it that way.

Pushed to HEAD and 9.5.

Joe




-- 
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers

Re: [HACKERS] more RLS oversights

[Joe Conway]

On 07/29/2015 01:01 AM, Dean Rasheed wrote:
 The CreatePolicy() and AlterPolicy() changes look OK to me, but the
 RemovePolicyById() change looks to be unnecessary ---
 RemovePolicyById() is called only from doDeletion(), which in turned
 is called only from deleteOneObject(), which already invokes the drop
 hooks. So ISTM that RemovePolicyById() doesn't need to do anything,
 right?

Seems correct. Will remove that change and commit it that way.

Joe



-- 
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers

Re: [HACKERS] more RLS oversights

[Joe Conway]

On 07/29/2015 02:41 AM, Dean Rasheed wrote:
 I don't think there is any point in adding the new function
 transformPolicyClause(), which is identical to transformWhereClause().
 You can just use transformWhereClause() with EXPR_KIND_POLICY. It's
 already used for lots of other expression kinds.


Ok -- I went back to using transformWhereClause. I'd still prefer to
change the name -- more than half the uses of the function are for other
than EXPR_KIND_WHERE -- but I don't feel that strongly about it.


 There are a couple of places in test_rls_hooks.c that also need updating.

done

 I think that check_agglevels_and_constraints() and
 transformWindowFuncCall() could be made to emit more targeted error
 messages for EXPR_KIND_POLICY, for example aggregate functions are
 not allowed in policy USING and WITH CHECK expressions.

done

Unless there are other comments/objections, will commit this later today.

Joe

diff --git a/src/backend/commands/policy.c b/src/backend/commands/policy.c
index d8b4390..bcf4a8f 100644
*** a/src/backend/commands/policy.c
--- b/src/backend/commands/policy.c
*** CreatePolicy(CreatePolicyStmt *stmt)
*** 534,545 
  
  	qual = transformWhereClause(qual_pstate,
  copyObject(stmt-qual),
! EXPR_KIND_WHERE,
  POLICY);
  
  	with_check_qual = transformWhereClause(with_check_pstate,
  		   copyObject(stmt-with_check),
! 		   EXPR_KIND_WHERE,
  		   POLICY);
  
  	/* Fix up collation information */
--- 534,545 
  
  	qual = transformWhereClause(qual_pstate,
  copyObject(stmt-qual),
! EXPR_KIND_POLICY,
  POLICY);
  
  	with_check_qual = transformWhereClause(with_check_pstate,
  		   copyObject(stmt-with_check),
! 		   EXPR_KIND_POLICY,
  		   POLICY);
  
  	/* Fix up collation information */
*** AlterPolicy(AlterPolicyStmt *stmt)
*** 707,713 
  		addRTEtoQuery(qual_pstate, rte, false, true, true);
  
  		qual = transformWhereClause(qual_pstate, copyObject(stmt-qual),
! 	EXPR_KIND_WHERE,
  	POLICY);
  
  		/* Fix up collation information */
--- 707,713 
  		addRTEtoQuery(qual_pstate, rte, false, true, true);
  
  		qual = transformWhereClause(qual_pstate, copyObject(stmt-qual),
! 	EXPR_KIND_POLICY,
  	POLICY);
  
  		/* Fix up collation information */
*** AlterPolicy(AlterPolicyStmt *stmt)
*** 730,736 
  
  		with_check_qual = transformWhereClause(with_check_pstate,
  			   copyObject(stmt-with_check),
! 			   EXPR_KIND_WHERE,
  			   POLICY);
  
  		/* Fix up collation information */
--- 730,736 
  
  		with_check_qual = transformWhereClause(with_check_pstate,
  			   copyObject(stmt-with_check),
! 			   EXPR_KIND_POLICY,
  			   POLICY);
  
  		/* Fix up collation information */
diff --git a/src/backend/parser/parse_agg.c b/src/backend/parser/parse_agg.c
index 478d8ca..e33adf5 100644
*** a/src/backend/parser/parse_agg.c
--- b/src/backend/parser/parse_agg.c
*** check_agglevels_and_constraints(ParseSta
*** 373,378 
--- 373,385 
  		case EXPR_KIND_WHERE:
  			errkind = true;
  			break;
+ 		case EXPR_KIND_POLICY:
+ 			if (isAgg)
+ err = _(aggregate functions are not allowed in POLICY USING and WITH CHECK expressions);
+ 			else
+ err = _(grouping operations are not allowed in POLICY USING and WITH CHECK expressions);
+ 
+ 			break;
  		case EXPR_KIND_HAVING:
  			/* okay */
  			break;
*** transformWindowFuncCall(ParseState *psta
*** 770,775 
--- 777,785 
  		case EXPR_KIND_WHERE:
  			errkind = true;
  			break;
+ 		case EXPR_KIND_POLICY:
+ 			err = _(aggregate functions are not allowed in POLICY USING and WITH CHECK expressions);
+ 			break;
  		case EXPR_KIND_HAVING:
  			errkind = true;
  			break;
diff --git a/src/backend/parser/parse_expr.c b/src/backend/parser/parse_expr.c
index 0ff46dd..fa77ef1 100644
*** a/src/backend/parser/parse_expr.c
--- b/src/backend/parser/parse_expr.c
*** transformSubLink(ParseState *pstate, Sub
*** 1672,1677 
--- 1672,1678 
  		case EXPR_KIND_FROM_SUBSELECT:
  		case EXPR_KIND_FROM_FUNCTION:
  		case EXPR_KIND_WHERE:
+ 		case EXPR_KIND_POLICY:
  		case EXPR_KIND_HAVING:
  		case EXPR_KIND_FILTER:
  		case EXPR_KIND_WINDOW_PARTITION:
*** ParseExprKindName(ParseExprKind exprKind
*** 3173,3178 
--- 3174,3181 
  			return function in FROM;
  		case EXPR_KIND_WHERE:
  			return WHERE;
+ 		case EXPR_KIND_POLICY:
+ 			return POLICY;
  		case EXPR_KIND_HAVING:
  			return HAVING;
  		case EXPR_KIND_FILTER:
diff --git a/src/include/parser/parse_node.h b/src/include/parser/parse_node.h
index 7ecaffc..5249945 100644
*** a/src/include/parser/parse_node.h
--- b/src/include/parser/parse_node.h
*** typedef enum ParseExprKind
*** 63,69 
  	EXPR_KIND_INDEX_PREDICATE,	/* index predicate */
  	EXPR_KIND_ALTER_COL_TRANSFORM,		/* transform expr in 

Re: [HACKERS] more RLS oversights

[Joe Conway]

On 07/29/2015 02:56 PM, Joe Conway wrote:
 On 07/29/2015 02:04 PM, Alvaro Herrera wrote:
 Why not just in policy expressions?  There's no third kind that does
 allow these.

 WFM
 
 Sold! Will do it that way.

Committed/pushed to HEAD and 9.5.

Joe




-- 
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers

Re: [HACKERS] more RLS oversights

[Joe Conway]

On 07/29/2015 01:26 PM, Robert Haas wrote:
 On Wed, Jul 29, 2015 at 3:58 PM, Alvaro Herrera
 alvhe...@2ndquadrant.com wrote:
 I think this reads a bit funny.  What's a POLICY USING clause?  I
 expect that translators will treat the two words POLICY USING as a
 single token, and the result is not going to make any sense.

 Maybe in a policy's USING and WITH CHECK expressions, or perhaps in
 policies's USING and WITH CHECK exprs, not sure.
 
 Yeah, I don't see why we would capitalize POLICY there.

The equivalent message for functions is:
  .. are not allowed in functions in FROM

So how does this sound:
... are not allowed in policies in USING and WITH CHECK expressions
or perhaps more simply:
... are not allowed in policies in USING and WITH CHECK

Joe



-- 
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers

Re: [HACKERS] more RLS oversights

[Joe Conway]

On 07/29/2015 02:04 PM, Alvaro Herrera wrote:
 Why not just in policy expressions?  There's no third kind that does
 allow these.
 
 WFM

Sold! Will do it that way.

Joe



-- 
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers

Re: [HACKERS] dblink: add polymorphic functions.

[Joe Conway]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

On 07/29/2015 09:40 AM, Corey Huinker wrote:
 Say I've got a table my_partitioned_table (key1 integer, key2
 integer, metric1 integer, metric2 integer);
 
 And I've got many partitions on that table. My code lets you do
 something like this:
 
 select key1, key2, sum(metric1) as a_sum_of_sums, sum(metric2) as 
 another_sum_of_sums from
 execute_buncha_queries(null::my_partitioned_table, 
 'connection_string_thats_just_a_loopback', array['select key1,
 key2, sum(metric1), sum(metric2) from my_partition_p1 group by
 1,2', 'select key1, key2, sum(metric1), sum(metric2) from
 my_partition_p2 group by 1,2', ...]) group by 1,2

 I can't put a cast around execute_buncha_queries because the
 function won't know how to cast the results coming back from
 dblink.

Ok, gotcha. So Tom's nearby comment about allowing the
p_rowtype%TYPE syntax to be used in the CAST is spot on (as usual).
In other words, to get a complete solution for you we would need to
make both things work, so you could do this inside plpgsql:

  select * from cast(dblink(connstr, sql) as p_rowtype%TYPE);

where potentially connstr, sql, p_rowtype are all passed to plpgsql as
arguments. Correct?

Joe

-BEGIN PGP SIGNATURE-
Version: GnuPG v2.0.22 (GNU/Linux)

iQIcBAEBAgAGBQJVuRMWAAoJEDfy90M199hlT5sP/3GuKbvZC7Ods3i2SqtTGbTo
raFiKM87ZznswldNjDHVBEp+OntXzb0JbPUf6n/YJoEJGWE95wb40jez5snAV9lO
aJ7CD9P235OgVh7QVTeWIW5Who8Yj1Xx6NF/Gz/06pGoAXQj1QoznnUPYixur4dT
znjWW3XY6eFpfLzIBKIJmcskOKezgqj2F/kRJpgGYVaEm3okVkjubDjmPM5Vbaaa
sd/lDI5ByceIImzL8LaFeBWwUGLYRsP02zamfPiz3p1zMb+ViBvS+NiBG0kMZMCt
bzy6g0kxbLaxkKy/oEQXqinCNY3hEn8eZ7w4Os/3Zk9PCacZAKDrXfqBDTuE6zio
wy/nwBnoTvdBSk0gl+MKoVlmoy0iAV7Hl/R/KtdNdpCTL4Ja6R5V2c/sjWazxAg4
PymaTXi4/SNWTFwAYGJUfGL+i3CMNQfp4U/tGTVPGFZ8thss7FTVNIVR6ZcAzuPM
EHYDZ8cGaewqDF/HdPlJl4ypxF3aS8tzzApiFVpu35+2WHEacwljDV40l8z9Ee1V
E7R0oxG55fgRJKvLSn5Oj59U2iBXgcu0zLLhBhaVyOYhcIZbWe6xvF1UN/RNcOuz
Se10lYSXCTmz3q61HyCNnWFcOtgYSeFA3Lc79vgxJoZWmwnpHYoFEjQxr3qHFeeK
svkoix7k7t7YZUXGebbg
=vM1F
-END PGP SIGNATURE-


-- 
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers

Re: [HACKERS] CREATE FUNCTION .. LEAKPROOF docs

[Joe Conway]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

On 06/14/2015 03:46 AM, Dean Rasheed wrote:
 I think the docs for the LEAKPROOF option in create_function.sgml 
 ought to mention RLS as well as security barrier views. Also the 
 current text is no longer strictly correct in light of commit 
 dcbf5948e12aa60b4d6ab65b6445897dfc971e01. Suggested rewording 
 attached.

Any objections out there to this doc patch? It rings true and reads
well to me. I'd like to check another item off the 9.5 Open Items list..
.

- -- 
Joe Conway
-BEGIN PGP SIGNATURE-
Version: GnuPG v2.0.22 (GNU/Linux)

iQIcBAEBAgAGBQJVuWXbAAoJEDfy90M199hlVMkP/RO2Vn8hlslKfP+9ZxgCOQk+
YZPlufD10tvsiWtmjxM/czQVgc4OtzANLS4G9tSL0ICiINWckP8FtF6NLdykic17
inTG3wrU2Q/EH9eIio6RJg6iZ+619A21IrFQwlSOJWB1WlPHHdzUoL2YZJsviEyt
01XTb6P60yg11MENWZGKQzWhL0SgjtWliuI2OVb2UbpE2lHb4KBVyPtnn4LW8SyP
a7lJA7WeERAuwlt2C9EbywE1gDJCMOnVnBWHjKtc8fEQKjJGwi6MgXelGBE9QWlx
j2TTleHO270m20aXkIaz/LQX1fjpHonWgtwnW11v4IvGHXZLgN89NRdx2rndBs9z
lRl0t7DLQ0Fn+h6nB4RQdN8huJD12O8JEYvktYMHPjJrCVKgezxqw2e3xUBdCnU+
4eo0TrjQQKxzlQvqTc+dnKXWu/xgre6QNjS5AknoKqA6+MXtCQ6OW/uUKQNA8Amc
WcxjsIJZaLbqOAaODL9DhdufcCCL1rMWuAWAGH7tJwDeIRJOQDChQp5Dg2YmGU/Y
hYAH+bqvJPoo0kAsftgyVocdfp7rDGd3nP87Bg3fFLXobghNIXK1xpXe08IRhAEh
wdMT1Np91WNl9wCyOpUiFn9rmP4ZMALofbhofI5hIsj5dTXvMGxbvsDk7xMykujk
3CeKshcZK060TSo1G2Up
=9wOA
-END PGP SIGNATURE-
diff --git a/doc/src/sgml/ref/create_function.sgml b/doc/src/sgml/ref/create_function.sgml
new file mode 100644
index c5beb16..cc2098c
--- a/doc/src/sgml/ref/create_function.sgml
+++ b/doc/src/sgml/ref/create_function.sgml
@@ -350,9 +350,18 @@ CREATE [ OR REPLACE ] FUNCTION
effects.  It reveals no information about its arguments other than by
its return value.  For example, a function which throws an error message
for some argument values but not others, or which includes the argument
-   values in any error message, is not leakproof.   The query planner may
-   push leakproof functions (but not others) into views created with the
-   literalsecurity_barrier/literal option.  See
+   values in any error message, is not leakproof.  This affects how the
+   system executes queries against views created with the
+   literalsecurity_barrier/literal option or tables with row level
+   security enabled.  The system will enforce conditions from security
+   policies and security barrier views before any user-supplied conditions
+   from the query itself that contain non-leakproof functions, in order to
+   prevent the inadvertent exposure of data.  Functions and operators
+   marked as leakproof are assumed to be trustworthy, and may be executed
+   before conditions from security policies and security barrier views.
+   In addtion, functions which do not take arguments or which are not
+   passed any arguments from the security barrier view or table do not have
+   to be marked as leakproof to be executed before security conditions.  See
xref linkend=sql-createview and xref linkend=rules-privileges.
This option can only be set by the superuser.
   /para

-- 
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers

Re: [HACKERS] dblink: add polymorphic functions.

[Joe Conway]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

On 07/29/2015 05:13 PM, Tom Lane wrote:
 What's possibly more palatable is to introduce some other special
 notation for obtain the type of this expression at parse time.
 I'm thinking for example about
 
 SELECT x::pg_typeof(some_expression) FROM ...
 
 Maybe it would be too confusing to overload pg_typeof this way, 
 in which case we could choose some other name.  Aside from that 
 consideration, this approach would have the effect of preventing 
 pg_typeof from being used as an actual type name, or at least
 from being used as a type name that can have typmod, but that
 doesn't seem like a huge drawback.
 
 This way would have the rather nice property that some_expression
 could actually be any parseable expression, not merely a qualified
 variable name (which I think is the only case that we'd have had
 any hope of supporting with %TYPE).

You think this could be made to work?

SELECT x::TYPE OF(some_expression) FROM ...

Then we would also have:

SELECT CAST(x AS TYPE OF(some_expression)) FROM ...

Seems nicer than pg_typeof

- -- 
Joe Conway
-BEGIN PGP SIGNATURE-
Version: GnuPG v2.0.22 (GNU/Linux)

iQIcBAEBAgAGBQJVuW3GAAoJEDfy90M199hlY6UP/026qCp5sxSz8zsnY9FyqqMp
Xf+a1nlqZFB821zQtMx7NtKtxjiC45jqbPSerLqCSbbpMftLG/iy5+/wdWJqAIoK
283Q23hD6r7hPwR2nown3BH5F1AFGCppG5KWebOgl01jVQSWBfFiRLrImFi/2FVs
sp3fHFmONp2kIYoAZwyFyZXv2n4D9Qhp0tIq94Dz0LGaszsfpYObCapPkgwAgaYZ
TSk5FAmD+IIJsNadhuk6IfJRObY5DgLL5keJSiuNs4Xpixq72KjqgnYQeXqgoT6U
AOqEkyg/KejkBSmuZRtHc9qnewGPzQn9TBXZEGPF+/ifpHC7+gL2au97kUW35j5l
3Ox57hTTRgr3oRvrEkGN/1uM/yDiobXb2HOp70mIeuYAWp3juwfxZQybRMYCoM8a
O/oyJqTSX2Dn/GkzeAOxbaQJulMeJfkivnwak0BhdaX3d4bDJz1ylNgz/B4Gtcnn
x4FVdTEfTBGFKFmfyDB5iAvpRrDCCDYcd2KcHA1J34vm8Ccm6m3aauJoi4zqsubh
bQnia2aoIAtnIOei/zVaST7+G+B3WAod3MDmrctjkx1lACTIeQVHq7q/A3iUPwcF
7Lfu9vr/6IBsAlvkdsX7zNZsIzAlov+ObrKZHBxeq2lB31MH1jeulX8lx+131+aI
ATx7kmeBlB60dkccMEhv
=VgLe
-END PGP SIGNATURE-


-- 
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers

Re: [HACKERS] [COMMITTERS] pgsql: Row-Level Security Policies (RLS)

[Joe Conway]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

On 06/01/2015 02:21 AM, Dean Rasheed wrote:
 While going through this, I spotted another issue --- in a DML
 query with additional non-target relations, such as UPDATE t1 ..
 FROM t2 .., the old code was checking the UPDATE policies of both
 t1 and t2, but really I think it ought to be checking the SELECT
 policies of t2 (in the same way as this query requires SELECT table
 permissions on t2, not UPDATE permissions). I've changed that and
 added new regression tests to test that change.

I assume the entire refactoring patch needs a fair bit of work to
rebase against current HEAD, but I picked out the attached to address
just the above issue. Does this look correct, and if so does it make
sense to apply at least this part right now?

Thanks,

Joe

-BEGIN PGP SIGNATURE-
Version: GnuPG v2.0.22 (GNU/Linux)

iQIcBAEBAgAGBQJVuXFuAAoJEDfy90M199hlOMkP/RZoBU0MJF64GjHfuLVa3T5w
PnDrnIoLBMOgOzkXrI+Ov0w0ESXltNvYjyIxkuyaB5PuoeDOdyYnnzbpPe7hH4pv
zDjSinJnfNmFEcm0UjBzuBiSH0dv52PEIToexTKu6SnjvH3Co/Hk4Ar2uZ0r7bRF
krl+Dd4kZX1uuRIigsSFqy873C79m3o11Szs5aW8c5od9adGxSvRHqZNf/UIDIbZ
CxAo0E3Tlw0DmGl1cw1tdN8gWMzmvx5dQ0ih3+0/hkVUqN9p3Pg8BGajSvxxFlb2
l4+6RZGUw5ZTpJxRZf/zPc4updhq0zf/Z5g7GUYddrhO29eLS6al2ySlb7HL5G9M
VPMjEzXuhFwhxSMdgHfz8UQh82KuNENMTKp81BvtIgZ7w86A9lWrKxCLaVMGhi8m
MnfCQ4cdOmnE2vEHi0Ue3Dg/rvYO8QpVW0JKDOdzoqPErC7to9vorXI5X3vcfLbF
fYfiJe6wUwbDEdxh/z0oKVFxWlf2NRk4pd+jZ7C+ibraLIwgEgZe7G4GEje5LxSP
h4zTfx0sj3IyrvqziurO/aZqIBXBZEsm3Gv6OQs26C5Xvkx/QmgROB42lHwcDYri
BTk6+uzNYKbX+kW56vEY0f0WMTLYZzc6jZRIVr3s+aLeyG0P9acY/n3uY1xBFCZZ
Xb7gmepAN3rY1CF7By9o
=e5hz
-END PGP SIGNATURE-
diff --git a/src/backend/rewrite/rowsecurity.c b/src/backend/rewrite/rowsecurity.c
index 2386cf0..562dbc9 100644
*** a/src/backend/rewrite/rowsecurity.c
--- b/src/backend/rewrite/rowsecurity.c
*** get_row_security_policies(Query *root, C
*** 147,154 
  		return;
  	}
  
! 	/* Grab the built-in policies which should be applied to this relation. */
  	rel = heap_open(rte-relid, NoLock);
  
  	rowsec_policies = pull_row_security_policies(commandType, rel,
   user_id);
--- 147,164 
  		return;
  	}
  
! 	/*
! 	 * RLS is enabled for this relation.
! 	 *
! 	 * Get the security policies that should be applied, based on the command
! 	 * type.  Note that if this isn't the target relation, we actually want
! 	 * the relation's SELECT policies, regardless of the query command type,
! 	 * for example in UPDATE t1 ... FROM t2 we need to apply t1's UPDATE
! 	 * policies and t2's SELECT policies.
! 	 */
  	rel = heap_open(rte-relid, NoLock);
+ 	if (rt_index != root-resultRelation)
+ 		commandType = CMD_SELECT;
  
  	rowsec_policies = pull_row_security_policies(commandType, rel,
   user_id);
diff --git a/src/test/regress/expected/rowsecurity.out b/src/test/regress/expected/rowsecurity.out
index b0556c2..6fc80af 100644
*** a/src/test/regress/expected/rowsecurity.out
--- b/src/test/regress/expected/rowsecurity.out
*** CREATE POLICY p ON t USING (max(c)); --
*** 3033,3038 
--- 3033,3121 
  ERROR:  aggregate functions are not allowed in policy expressions
  ROLLBACK;
  --
+ -- Non-target relations are only subject to SELECT policies
+ --
+ SET SESSION AUTHORIZATION rls_regress_user0;
+ CREATE TABLE r1 (a int);
+ CREATE TABLE r2 (a int);
+ INSERT INTO r1 VALUES (10), (20);
+ INSERT INTO r2 VALUES (10), (20);
+ GRANT ALL ON r1, r2 TO rls_regress_user1;
+ CREATE POLICY p1 ON r1 USING (true);
+ ALTER TABLE r1 ENABLE ROW LEVEL SECURITY;
+ CREATE POLICY p1 ON r2 FOR SELECT USING (true);
+ CREATE POLICY p2 ON r2 FOR INSERT WITH CHECK (false);
+ CREATE POLICY p3 ON r2 FOR UPDATE USING (false);
+ CREATE POLICY p4 ON r2 FOR DELETE USING (false);
+ ALTER TABLE r2 ENABLE ROW LEVEL SECURITY;
+ SET SESSION AUTHORIZATION rls_regress_user1;
+ SELECT * FROM r1;
+  a  
+ 
+  10
+  20
+ (2 rows)
+ 
+ SELECT * FROM r2;
+  a  
+ 
+  10
+  20
+ (2 rows)
+ 
+ -- r2 is read-only
+ INSERT INTO r2 VALUES (2); -- Not allowed
+ ERROR:  new row violates row level security policy for r2
+ UPDATE r2 SET a = 2 RETURNING *; -- Updates nothing
+  a 
+ ---
+ (0 rows)
+ 
+ DELETE FROM r2 RETURNING *; -- Deletes nothing
+  a 
+ ---
+ (0 rows)
+ 
+ -- r2 can be used as a non-target relation in DML
+ INSERT INTO r1 SELECT a + 1 FROM r2 RETURNING *; -- OK
+  a  
+ 
+  11
+  21
+ (2 rows)
+ 
+ UPDATE r1 SET a = r2.a + 2 FROM r2 WHERE r1.a = r2.a RETURNING *; -- OK
+  a  | a  
+ +
+  12 | 10
+  22 | 20
+ (2 rows)
+ 
+ DELETE FROM r1 USING r2 WHERE r1.a = r2.a + 2 RETURNING *; -- OK
+  a  | a  
+ +
+  12 | 10
+  22 | 20
+ (2 rows)
+ 
+ SELECT * FROM r1;
+  a  
+ 
+  11
+  21
+ (2 rows)
+ 
+ SELECT * FROM r2;
+  a  
+ 
+  10
+  20
+ (2 rows)
+ 
+ SET SESSION AUTHORIZATION rls_regress_user0;
+ DROP TABLE r1;
+ DROP TABLE r2;
+ --
  -- Clean up objects
  --
  RESET SESSION AUTHORIZATION;
diff --git a/src/test/regress/sql/rowsecurity.sql 

Re: [HACKERS] dblink: add polymorphic functions.

[Joe Conway]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

On 07/29/2015 07:58 PM, Tom Lane wrote:
 We can definitely do
 
 SELECT x::any_single_unreserved_word(some_expression) FROM ...
 
 because that's actually not something the grammar needs to
 distinguish from type-with-a-typmod; we can deal with the special
 case in LookupTypeName.  It's just a matter of picking a word
 people like.

What about just TYPE then?

SELECT x::TYPE(some_expression) FROM ...
SELECT CAST (x AS TYPE(some_expression)) FROM ...

- -- 
Joe Conway
-BEGIN PGP SIGNATURE-
Version: GnuPG v2.0.22 (GNU/Linux)

iQIcBAEBAgAGBQJVuar5AAoJEDfy90M199hlN8gP/i2IdtOsJ1PasKfUjAegbHf5
HIWLI7lZw2OMb451zrrNJbfTk1xY+OUJX8tRTLku8GyoZ9FrhDnBo0JuZuHMQOo4
ulWPH7JYGQVb89FYANNbubIehfJ0Y5TCr/ihkpmeVR6sTR3OZDSvdVtymF34wfZE
96i2S6QqWHN4V6hNXjTuzaIu4BXFXvZg3N9yNvBRrpnif53jfKPnca6wSeHJgTWv
w8L6mKQbLDW+5azVmuFX/1PyLxMRphsZL6G4+yyASkzQP2VOGDRQrM4Uavoot9Ja
l1Ez4bBoK3ERxfovnSWfwlsqhKmQ41TijoIu/Ex/s1O3dL2LVQ2qBp8cCl8pX9zq
Fnk11ueAvjkVt8/mIQFkGY+noes8vqWGe6yB0FYXjJvFfL4DXgfmthdyyCGJM1l9
JLI034tkflXKEkk5Ty9gOeAaMzqztqmIRYoQKK7O18DOKNH3Fgoa5Vh2Fz/iJI6G
rjQtfcZwv6ukN0qyQ8QB42CvLJVQ5KVwdTSr/93eCipSIuTPJNEoIBSh7H02WN7Q
fqQcKsM9m9ZTkAYP9uQCMEwusiKoPZt41Tdwf5fbhuOHoSim2Tab63eMEoUkRsqu
Bgqql/U5/MRsoAoDp4ALr2LbugnnTVNhrqrP58e45yl+694UEyh9XRpZmWUpX9Lw
k+qPyOJCnLBwOcmS0tv1
=+T37
-END PGP SIGNATURE-


-- 
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers

Re: [HACKERS] more RLS oversights

[Joe Conway]

On 07/03/2015 10:03 AM, Noah Misch wrote:
 (6) AlterPolicy() calls InvokeObjectPostAlterHook(PolicyRelationId, ...), but
 CreatePolicy() and DropPolicy() lack their respective hook invocations.

Patch attached. Actually AlterPolicy() was also missing its hook -- the
existing InvokeObjectPostAlterHook() was only in rename_policy().

I'm not 100% sure about the hook placement -- would appreciate if
someone could confirm I got it correct.

Joe

diff --git a/src/backend/commands/policy.c b/src/backend/commands/policy.c
index 4642d7c..77aaaca 100644
*** a/src/backend/commands/policy.c
--- b/src/backend/commands/policy.c
*** RemovePolicyById(Oid policy_id)
*** 410,415 
--- 410,417 
  	if (!HeapTupleIsValid(tuple))
  		elog(ERROR, could not find tuple for policy %u, policy_id);
  
+ 	InvokeObjectDropHook(PolicyRelationId, policy_id, 0);
+ 
  	/*
  	 * Open and exclusive-lock the relation the policy belong to.
  	 */
*** CreatePolicy(CreatePolicyStmt *stmt)
*** 629,634 
--- 631,638 
  	 SHARED_DEPENDENCY_POLICY);
  	}
  
+ 	InvokeObjectPostCreateHook(PolicyRelationId, policy_id, 0);
+ 
  	/* Invalidate Relation Cache */
  	CacheInvalidateRelcache(target_table);
  
*** AlterPolicy(AlterPolicyStmt *stmt)
*** 860,865 
--- 864,871 
  	 SHARED_DEPENDENCY_POLICY);
  	}
  
+ 	InvokeObjectPostAlterHook(PolicyRelationId, policy_id, 0);
+ 
  	heap_freetuple(new_tuple);
  
  	/* Invalidate Relation Cache */

-- 
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers

Re: [HACKERS] more RLS oversights

[Joe Conway]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

On 07/27/2015 05:34 PM, Joe Conway wrote:
 On 07/27/2015 01:13 PM, Alvaro Herrera wrote:
 Hmm, these are not ACL objects, so conceptually it seems cleaner
 to use a different symbol for this.  I think the catalog state
 and the error messages would be a bit confusing otherwise.
 
 Ok -- done
 
 Isn't this leaking the previously allocated array?  Not sure
 it's all that critical, but still.  (I don't think you really
 need to call palloc at all here.)
 
 Agreed -- I think the attached is a bit cleaner.
 
 Any other comments or concerns?

Pushed to HEAD and 9.5

Joe


-BEGIN PGP SIGNATURE-
Version: GnuPG v2.0.22 (GNU/Linux)

iQIcBAEBAgAGBQJVuAp9AAoJEDfy90M199hlokgP/2RVYjPiwM0EcE9pAdGP3Uqa
qkCqj5cPq/5SdLH553h/Xd6056qwchoMJYQo9RZzzVR4wS4HPyeZ00e33RrJZbtm
MGvjat1NJWEyl03y1AwAy9c9yHCRJa5vQlKtm0v2xWDG3xXqwejz/SK2ijw2IWVW
W1/7OnObbquHa7a+IsO1ndXoI0jECzOFDXY6YzFVJuPAf3asOHT44lJbHkfUq3Kv
k5eK14Xrb3kcYqhBQg+eG50lr1aRDj8yDlYQuoGmw/dg/X0TyAo2v+AOaFrN8rXD
igsYaMDafsXY55izkiRuNfcYZAnHC7hNVt+ffV+wLycCTiaEEflp+BCxLTYmh53T
xDB39Lr0Sz7AP77l0M9hbMr3Ao3GA1KFOc9OfRN11eSo5Y6uDtpMeOIFBAke6hxl
DanWPc/YmXzacga99xzOQglDZkDWTohWsEDwniRJmi7UC0Z/gwZ2P60OnwE1lqbd
eOmUu0JZCwklInWoDo9XmWdfp9+OrviGNm0vhQbplhEm/LC9PqBB/DOy44QjSv84
jfY/iMPn8uvGqWiQ/65za1O/1QsRukgp5PVnj7TyNojSskSuAYOF5BcFVIdB7krj
ZKHChreUMVw1nH8py4HkdPOXTHmAItV9/9T2c/UUuJWAECiLy+tIY/if+Tzi+Zn6
nRm99YM401PAsRKLyn0m
=gYmH
-END PGP SIGNATURE-


-- 
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers

Re: [HACKERS] more RLS oversights

[Joe Conway]

On 07/03/2015 10:03 AM, Noah Misch wrote:
 (4) When DefineQueryRewrite() is about to convert a table to a view, it checks
 the table for features unavailable to views.  For example, it rejects tables
 having triggers.  It omits to reject tables having relrowsecurity or a
 pg_policy record.  Test case:

Please see the attached patch for this issue. Comments?

Thanks,

Joe

diff --git a/src/backend/commands/policy.c b/src/backend/commands/policy.c
index 17b48d4..aa858fa 100644
*** a/src/backend/commands/policy.c
--- b/src/backend/commands/policy.c
*** get_relation_policy_oid(Oid relid, const
*** 1002,1004 
--- 1002,1033 
  
  	return policy_oid;
  }
+ 
+ /*
+  * relation_has_policies - Determine if relation has any policies
+  */
+ bool
+ relation_has_policies(Relation rel)
+ {
+ 	Relation	catalog;
+ 	ScanKeyData skey;
+ 	SysScanDesc sscan;
+ 	HeapTuple	policy_tuple;
+ 	bool		ret = false;
+ 
+ 	catalog = heap_open(PolicyRelationId, AccessShareLock);
+ 	ScanKeyInit(skey,
+ Anum_pg_policy_polrelid,
+ BTEqualStrategyNumber, F_OIDEQ,
+ ObjectIdGetDatum(RelationGetRelid(rel)));
+ 	sscan = systable_beginscan(catalog, PolicyPolrelidPolnameIndexId, true,
+ 			   NULL, 1, skey);
+ 	policy_tuple = systable_getnext(sscan);
+ 	if (HeapTupleIsValid(policy_tuple))
+ 		ret = true;
+ 
+ 	systable_endscan(sscan);
+ 	heap_close(catalog, AccessShareLock);
+ 
+ 	return ret;
+ }
diff --git a/src/backend/rewrite/rewriteDefine.c b/src/backend/rewrite/rewriteDefine.c
index a88d73e..39c83a6 100644
*** a/src/backend/rewrite/rewriteDefine.c
--- b/src/backend/rewrite/rewriteDefine.c
***
*** 27,32 
--- 27,33 
  #include catalog/objectaccess.h
  #include catalog/pg_rewrite.h
  #include catalog/storage.h
+ #include commands/policy.h
  #include miscadmin.h
  #include nodes/nodeFuncs.h
  #include parser/parse_utilcmd.h
*** DefineQueryRewrite(char *rulename,
*** 410,420 
  		 *
  		 * If so, check that the relation is empty because the storage for the
  		 * relation is going to be deleted.  Also insist that the rel not have
! 		 * any triggers, indexes, or child tables.  (Note: these tests are too
! 		 * strict, because they will reject relations that once had such but
! 		 * don't anymore.  But we don't really care, because this whole
! 		 * business of converting relations to views is just a kluge to allow
! 		 * dump/reload of views that participate in circular dependencies.)
  		 */
  		if (event_relation-rd_rel-relkind != RELKIND_VIEW 
  			event_relation-rd_rel-relkind != RELKIND_MATVIEW)
--- 411,422 
  		 *
  		 * If so, check that the relation is empty because the storage for the
  		 * relation is going to be deleted.  Also insist that the rel not have
! 		 * any triggers, indexes, child tables, policies, or RLS enabled.
! 		 * (Note: these tests are too strict, because they will reject
! 		 * relations that once had such but don't anymore.  But we don't
! 		 * really care, because this whole business of converting relations
! 		 * to views is just a kluge to allow dump/reload of views that
! 		 * participate in circular dependencies.)
  		 */
  		if (event_relation-rd_rel-relkind != RELKIND_VIEW 
  			event_relation-rd_rel-relkind != RELKIND_MATVIEW)
*** DefineQueryRewrite(char *rulename,
*** 451,456 
--- 453,470 
  		 errmsg(could not convert table \%s\ to a view because it has child tables,
  RelationGetRelationName(event_relation;
  
+ 			if (event_relation-rd_rel-relrowsecurity)
+ ereport(ERROR,
+ 		(errcode(ERRCODE_OBJECT_NOT_IN_PREREQUISITE_STATE),
+ 		 errmsg(could not convert table \%s\ to a view because it has row security enabled,
+ RelationGetRelationName(event_relation;
+ 
+ 			if (relation_has_policies(event_relation))
+ ereport(ERROR,
+ 		(errcode(ERRCODE_OBJECT_NOT_IN_PREREQUISITE_STATE),
+ 		 errmsg(could not convert table \%s\ to a view because it has row security policies,
+ RelationGetRelationName(event_relation;
+ 
  			RelisBecomingView = true;
  		}
  	}
diff --git a/src/include/commands/policy.h b/src/include/commands/policy.h
index ac322e0..be00043 100644
*** a/src/include/commands/policy.h
--- b/src/include/commands/policy.h
*** extern Oid get_relation_policy_oid(Oid r
*** 31,35 
--- 31,36 
  
  extern ObjectAddress rename_policy(RenameStmt *stmt);
  
+ extern bool relation_has_policies(Relation rel);
  
  #endif   /* POLICY_H */
diff --git a/src/test/regress/expected/rowsecurity.out b/src/test/regress/expected/rowsecurity.out
index 72361e8..2a8db6d 100644
*** a/src/test/regress/expected/rowsecurity.out
--- b/src/test/regress/expected/rowsecurity.out
*** SELECT * FROM coll_t;
*** 2908,2913 
--- 2908,2936 
  
  ROLLBACK;
  --
+ -- Converting table to view
+ --
+ BEGIN;
+ SET ROW_SECURITY = FORCE;
+ CREATE TABLE t (c int);
+ CREATE POLICY p ON t USING (c % 2 = 1);
+ ALTER TABLE t ENABLE ROW LEVEL SECURITY;
+ 

Re: [HACKERS] more RLS oversights

[Joe Conway]

On 07/03/2015 10:03 AM, Noah Misch wrote:
 (7) Using an aggregate function in a policy predicate elicits an inapposite
 error message due to use of EXPR_KIND_WHERE for parse analysis.  Need a new
 ParseExprKind.  Test case:

Patch attached. Comments?

Joe


diff --git a/src/backend/commands/policy.c b/src/backend/commands/policy.c
index 4642d7c..d8ef496 100644
*** a/src/backend/commands/policy.c
--- b/src/backend/commands/policy.c
*** CreatePolicy(CreatePolicyStmt *stmt)
*** 532,545 
  		NULL, false, false);
  	addRTEtoQuery(with_check_pstate, rte, false, true, true);
  
! 	qual = transformWhereClause(qual_pstate,
  copyObject(stmt-qual),
! EXPR_KIND_WHERE,
  POLICY);
  
! 	with_check_qual = transformWhereClause(with_check_pstate,
  		   copyObject(stmt-with_check),
! 		   EXPR_KIND_WHERE,
  		   POLICY);
  
  	/* Fix up collation information */
--- 532,545 
  		NULL, false, false);
  	addRTEtoQuery(with_check_pstate, rte, false, true, true);
  
! 	qual = transformPolicyClause(qual_pstate,
  copyObject(stmt-qual),
! EXPR_KIND_POLICY,
  POLICY);
  
! 	with_check_qual = transformPolicyClause(with_check_pstate,
  		   copyObject(stmt-with_check),
! 		   EXPR_KIND_POLICY,
  		   POLICY);
  
  	/* Fix up collation information */
*** AlterPolicy(AlterPolicyStmt *stmt)
*** 704,711 
  
  		addRTEtoQuery(qual_pstate, rte, false, true, true);
  
! 		qual = transformWhereClause(qual_pstate, copyObject(stmt-qual),
! 	EXPR_KIND_WHERE,
  	POLICY);
  
  		/* Fix up collation information */
--- 704,711 
  
  		addRTEtoQuery(qual_pstate, rte, false, true, true);
  
! 		qual = transformPolicyClause(qual_pstate, copyObject(stmt-qual),
! 	EXPR_KIND_POLICY,
  	POLICY);
  
  		/* Fix up collation information */
*** AlterPolicy(AlterPolicyStmt *stmt)
*** 726,734 
  
  		addRTEtoQuery(with_check_pstate, rte, false, true, true);
  
! 		with_check_qual = transformWhereClause(with_check_pstate,
  			   copyObject(stmt-with_check),
! 			   EXPR_KIND_WHERE,
  			   POLICY);
  
  		/* Fix up collation information */
--- 726,734 
  
  		addRTEtoQuery(with_check_pstate, rte, false, true, true);
  
! 		with_check_qual = transformPolicyClause(with_check_pstate,
  			   copyObject(stmt-with_check),
! 			   EXPR_KIND_POLICY,
  			   POLICY);
  
  		/* Fix up collation information */
diff --git a/src/backend/parser/parse_agg.c b/src/backend/parser/parse_agg.c
index 478d8ca..b79e73d 100644
*** a/src/backend/parser/parse_agg.c
--- b/src/backend/parser/parse_agg.c
*** check_agglevels_and_constraints(ParseSta
*** 373,378 
--- 373,381 
  		case EXPR_KIND_WHERE:
  			errkind = true;
  			break;
+ 		case EXPR_KIND_POLICY:
+ 			errkind = true;
+ 			break;
  		case EXPR_KIND_HAVING:
  			/* okay */
  			break;
*** transformWindowFuncCall(ParseState *psta
*** 770,775 
--- 773,781 
  		case EXPR_KIND_WHERE:
  			errkind = true;
  			break;
+ 		case EXPR_KIND_POLICY:
+ 			errkind = true;
+ 			break;
  		case EXPR_KIND_HAVING:
  			errkind = true;
  			break;
diff --git a/src/backend/parser/parse_clause.c b/src/backend/parser/parse_clause.c
index 5980856..7063e5f 100644
*** a/src/backend/parser/parse_clause.c
--- b/src/backend/parser/parse_clause.c
*** transformWhereClause(ParseState *pstate,
*** 1465,1470 
--- 1465,1491 
  	return qual;
  }
  
+ /*
+  * transformPolicyClause -
+  *	  Transform USING and WITH CHECK expr to make sure it is of type boolean.
+  *
+  * constructName does not affect the semantics, but is used in error messages
+  */
+ Node *
+ transformPolicyClause(ParseState *pstate, Node *clause,
+ 	  ParseExprKind exprKind, const char *constructName)
+ {
+ 	Node	   *qual;
+ 
+ 	if (clause == NULL)
+ 		return NULL;
+ 
+ 	qual = transformExpr(pstate, clause, exprKind);
+ 
+ 	qual = coerce_to_boolean(pstate, qual, constructName);
+ 
+ 	return qual;
+ }
  
  /*
   * transformLimitClause -
diff --git a/src/backend/parser/parse_expr.c b/src/backend/parser/parse_expr.c
index 0ff46dd..fa77ef1 100644
*** a/src/backend/parser/parse_expr.c
--- b/src/backend/parser/parse_expr.c
*** transformSubLink(ParseState *pstate, Sub
*** 1672,1677 
--- 1672,1678 
  		case EXPR_KIND_FROM_SUBSELECT:
  		case EXPR_KIND_FROM_FUNCTION:
  		case EXPR_KIND_WHERE:
+ 		case EXPR_KIND_POLICY:
  		case EXPR_KIND_HAVING:
  		case EXPR_KIND_FILTER:
  		case EXPR_KIND_WINDOW_PARTITION:
*** ParseExprKindName(ParseExprKind exprKind
*** 3173,3178 
--- 3174,3181 
  			return function in FROM;
  		case EXPR_KIND_WHERE:
  			return WHERE;
+ 		case EXPR_KIND_POLICY:
+ 			return POLICY;
  		case EXPR_KIND_HAVING:
  			return HAVING;
  		case EXPR_KIND_FILTER:
diff --git a/src/include/parser/parse_clause.h 

Re: [HACKERS] A little RLS oversight?

[Joe Conway]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

On 07/28/2015 12:32 AM, Dean Rasheed wrote:
 On 07/27/2015 03:05 PM, Stephen Frost wrote:
 AFK at the moment, but my thinking was that we should avoid
 having the error message change based on what a GUC is set to.
 I agree that there should be comments which explain that.
 
 Except it's already dependent on the GUC if it's set to FORCE.

Dean is correct. See test case below...

 I changed back to using GetUserId() for the call to
 check_enable_rls() at those three call sites, and added to the
 comments to explain why.
 
 
 I'm not entirely convinced about this. The more I think about it,
 the more I think that if we know the user has BYPASSRLS, and
 they've set row_security to OFF, then they ought to get the more
 detailed error message, as they would if there was no RLS. That
 error detail is highly useful, and we know the user has been
 granted privilege by a superuser, and that they have direct access
 to the underlying table in this context, so we're not leaking any
 info that they cannot directly SELECT anyway.

Agreed -- this patch version goes back to using InvalidOid at those
three call sites and the behavior is what I now believe to be correct.
Here is a test case to illustrate:

8
BEGIN;
CREATE ROLE alice;
CREATE ROLE bob WITH BYPASSRLS;

SET SESSION AUTHORIZATION alice;
CREATE TABLE t1 (id int primary key, f1 text);
INSERT INTO t1 VALUES(1,'a');
CREATE TABLE t2 (id int primary key, f1 text, t1_id int REFERENCES
t1(id));
GRANT ALL ON t2 TO bob;
ALTER TABLE t2 ENABLE ROW LEVEL SECURITY;
CREATE POLICY P ON t2 TO alice, bob USING (true);

SET SESSION AUTHORIZATION bob;
INSERT INTO t2 VALUES(1,'a',1); -- should succeed

SAVEPOINT q;
INSERT INTO t2 VALUES(2,'b',2); -- should fail, no details
ROLLBACK TO q;

SET row_security = OFF;
SAVEPOINT q;
INSERT INTO t2 VALUES(2,'b',2); -- should fail, full details
ROLLBACK TO q;

SET SESSION AUTHORIZATION alice;
SAVEPOINT q;
INSERT INTO t2 VALUES(2,'b',2); -- should fail, full details
ROLLBACK TO q;

SET row_security = FORCE;
SAVEPOINT q;
INSERT INTO t2 VALUES(2,'b',2); -- should fail, no details
ROLLBACK TO q;

ROLLBACK;
8

I'm going to commit the attached in the next few hours unless someone
has serious objections. We can always revisit the specific behavior of
those messages separately if we change our minds...

Joe

-BEGIN PGP SIGNATURE-
Version: GnuPG v2.0.22 (GNU/Linux)

iQIcBAEBAgAGBQJVt8dQAAoJEDfy90M199hl1ncQAI/XUZ3VSoW0Vegf09Y2DqlJ
f8lGnwSf+djSXgKVrUsKQsuLn7c+Ac9fqoRUQJMuCcOvnu7auljzaMjuMjrXhOIC
hhiP8QyYUoEMF+5Sggh/A532rFXRbI1R/g9eu8TTT9vJGkITVMGAucizSY+fPiBg
gH3JyuCVaIZbvlVv0OkqPXPiP1VR/7bDTBcIbv56XHOk1AavNlUMW5BWWR0/9Mt8
VMh9ri3eQ5beKxrDhAZ+39ddlQzk9yJsN5pd/Pu0zPNxwBcvTNra0ZZGv7PoPwUF
7F98A1bL/NWFDdFuOI2E61/a5lA70t5HV4UTPPugQr82NhBS9JdpxgqA8W7B9+P9
4TKqmmYIvOcxM+TtglIlyr+JBwfJERw8j3+IcnM3mjLnkyflNbX2kbOF0B5Ghpt/
EzrVIJi/Pl3ctm+9r/oQYiwo/6Qsy8hco9QLCY4GVhBEE93Wr8P6NVlcjzyocMRs
FBjgvxeL/1wL8g3Q8ZDsAVOu9Ld0OCGEkA27XRS3sXbZfHroeTNW5aUqvKIzFkKB
gsr09pIVtdd7ysEdxxHZpELaU8H2rcA5O8b380HauIi41GaDc5E0XLXJSu6dIWCP
x/Em3qTpt74YgZiqsbs3a21Ak5n8fBdTMyXhmPQbXctllALI3Kj7bbyqoeGywpxi
PKhGDzgw+M7OQzfWS7UF
=e5Qo
-END PGP SIGNATURE-
diff --git a/doc/src/sgml/func.sgml b/doc/src/sgml/func.sgml
index 98d1497..fd82ea4 100644
*** a/doc/src/sgml/func.sgml
--- b/doc/src/sgml/func.sgml
*** SET search_path TO replaceableschema/
*** 15259,15264 
--- 15259,15270 
 entrytypeboolean/type/entry
 entrydoes current user have privilege for role/entry
/row
+   row
+entryliteralfunctionrow_security_active/function(parametertable/parameter)/literal
+/entry
+entrytypeboolean/type/entry
+entrydoes current user have row level security active for table/entry
+   /row
   /tbody
  /tgroup
 /table
*** SET search_path TO replaceableschema/
*** 15299,15304 
--- 15305,15313 
 indexterm
  primarypg_has_role/primary
 /indexterm
+indexterm
+ primaryrow_security_active/primary
+/indexterm
  
 para
  functionhas_table_privilege/function checks whether a user
*** SELECT has_function_privilege('joeuser',
*** 15462,15467 
--- 15471,15483 
  are immediately available without doing commandSET ROLE/.
 /para
  
+para
+ functionrow_security_active/function checks whether row level
+ security is active for the specified table in the context of the
+ functioncurrent_user/function and environment. The table can
+ be specified by name or by OID.
+/para
+ 
para
 xref linkend=functions-info-schema-table shows functions that
 determine whether a certain object is firsttermvisible/ in the
diff --git a/src/backend/access/index/genam.c b/src/backend/access/index/genam.c
index 1043362..aa5b28c 100644
*** a/src/backend/access/index/genam.c
--- b/src/backend/access/index/genam.c
*** 

Re: [HACKERS] more RLS oversights

[Joe Conway]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

On 07/28/2015 11:50 AM, Stephen Frost wrote:
 * Joe Conway (joe.con...@crunchydata.com) wrote:
 On 07/03/2015 10:03 AM, Noah Misch wrote:
 (4) When DefineQueryRewrite() is about to convert a table to a
 view, it checks the table for features unavailable to views.
 For example, it rejects tables having triggers.  It omits to
 reject tables having relrowsecurity or a pg_policy record.
 Test case:
 
 Please see the attached patch for this issue. Comments?
 
 Looks good to me.

Thanks -- pushed to HEAD and 9.5

Joe


-BEGIN PGP SIGNATURE-
Version: GnuPG v2.0.22 (GNU/Linux)

iQIcBAEBAgAGBQJVuA+UAAoJEDfy90M199hlrtYQAJGVucRtarWTQoP39of8IYXE
OoAi+q6CKEJWEJdVHmnnCwMc6y0lx0+Qugpb5SAVqMG/0oYvZ/bnvvN5OHMxujCI
bw7A/eJ62BILAt07Oczs1gtt+k4PT1001c4jFjgSC6AV51cZ9UM+d0b4C2YhKcm7
B4tycmC/yGxa5UFT6vdOhneILzBeOMLxgMXKouoD7Gnf4UKh1KUWxxWKU9q0Kl7d
mvRJke1wj/+WfquO09g33+1jHCsnbV4fcQ1q8RQbFPItpqcp4alsuuIYzLiPRbbs
VtZYurFLpjKdJg8OuHw9IYNbDjPZoEuv5eV16aSjOJxnngcXROxwXOwZMVaCuQMq
1D5FoUunJqsqlxVKggJJLfBt9uM/gafjmnRHGBZftfX/A3ZM6c6YewA68Nxo+rTE
xtgA+n1lzWsahje0n2KSFUNRSCqdWcnLQ/HtnVcNjGdFdCxeUDQ5kUAE1hFCMCXe
5eqAvohQQ25RiurZ1rI1IfUoeAPRDp3nvgcMMM7FQMmv6oKNBLr2RivVz0ZE17vd
Htz0y0cPx8mJgEHKMJrV/yF9odECTxevBzkO5rASLCLnGHEYp8WZfqWO/s/HoujS
KU99lfzOfnyBIyl2zIGSmkmCvUIqaP1cUP5xMHIedNhjDRy/Rt6IxwA9qEtgUokI
sC6BWHpxd19RAh5NLXCK
=NFOR
-END PGP SIGNATURE-


-- 
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers

Re: [HACKERS] A little RLS oversight?

[Joe Conway]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

On 07/28/2015 11:17 AM, Joe Conway wrote:
 I'm going to commit the attached in the next few hours unless
 someone has serious objections. We can always revisit the specific
 behavior of those messages separately if we change our minds...

Pushed to master and 9.5

Joe
-BEGIN PGP SIGNATURE-
Version: GnuPG v2.0.22 (GNU/Linux)

iQIcBAEBAgAGBQJVt+U0AAoJEDfy90M199hlPb8P/0cgoaY4YWIcGc2HsezMAvfn
Fx2NqTpN7i1HCkWZcVv85TqfY4lura9wkakHOf6WFPSfBPMKGwBjDOPGwDc/iR42
RchChOXFK8Up12iqEZJMQ8PJQoaN3ZWg2QRrIpxPlQkhxsOKDDR9ZehczYSRrK5P
Nx/PE+cCHvI48zRQ0b31uPTeYMtUoCu/7qPQeSk3es/K5x3GBGls8aV/drw3CBRK
nrq7wu84jCrENoRhJSYKnntpjtBF43/SSojnJd0uOL6dytdEztxfyugEDnGni46k
vdEJNewKPIqZR5V8Qa4UGF4YKzxH8IgyWpYOuHTeNTEnNY+3/D+jmJoIwNw/P7gn
t+MMj6m4oRvWFY/J6sRZJ7bsFwj9KexQuu2rGDesnpWbJE5B7IricyUdtDrgia7p
qCS5wEnoG9uTrisPNi+oMZ1+IdsZ0FOHjfq6pNUUGDlmdR/iN4A8iNrAxIto5mHy
mB1Fx37LsMxeknDNQvsepOVa573goGlLwEDb5slxDySEGdXx6vm2pQo+Yy+L5s1g
dsFM7aVhCzsPjHZLKM9hEb84cjor7YzjuKlkQKfLkr7e6v6N2mtk/PTGYR51+li5
/8eZUxNF9K9tVe8dtP+RGtQ7ZgwmzOXcR34v6JYXOJz+X0DBT9c50A3986KMMS2X
1FrY7SUZlzMxRExmPXGH
=0YFQ
-END PGP SIGNATURE-


-- 
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers

Re: [HACKERS] Remaining 'needs review' patchs in July commitfest

[Joe Conway]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

On 07/28/2015 01:22 PM, Heikki Linnakangas wrote:
 dblink: add polymorphic result functions
 
 Seems pretty ugly to me to add a dummy argument to functions,
 just so that you can specify the result type. The problem it's
 trying to solve is real, though. Should we take it as it is, or
 wait for some cleaner approach?
 
 Put like that, it does sound quite ugly.  I take it we have no
 better alternative proposed?
 
 Joe Conway suggested a more generic approach here: 
 http://www.postgresql.org/message-id/559a9643.9070...@joeconway.com.
 I'm not sure why that was not pursued. It certainly seems better to
 me.

I really think the second approach in that email is the right way to
go. Is there any benefit we get from the dblink specific hack that we
don't get via the cast?

I guess it is just be a matter of someone getting around to making it
happen. I can put it on my list of things to do, but probably will not
get to looking at it for at least a few more weeks.

- -- 
Joe Conway
-BEGIN PGP SIGNATURE-
Version: GnuPG v2.0.22 (GNU/Linux)

iQIcBAEBAgAGBQJVt+xpAAoJEDfy90M199hlIM8P/iRq3nZo6Q/u14D9Vqvd8qZ1
cPaBgGoHvCCuM3rS/z0DobBMjKll0oEerjXeuBKTjWBwilPrdHMZahueFZ1896Mh
atcj7kz8O3nBj27sBAHI1tXCTPRkjOIpt6nNu8BEsG8mUmX8wC2odfyGFZIKzw2j
dtLGsczSMwrXnE1yTzgCYWVl0ej8y/CtAmL6uEQOIA5XDHmYe6EqqPd3rcNBNg+I
endHrAXGm/VVsKGUJfisWItVbPJy4VBx1y1iXfApxePceHjW6/U0Ivds5Qu+K3wd
0pwsBmqlHNBGzwril1jBpm9gecIYY6916Hbru7Fafae4bbFHRTDw0ExURybrlhGo
MjOhWmfpsCutGmBktgWxqiOY9UDnG1+aXREKIv7bIavPhBYbBRkvqT7qrAKureex
y2XZz86tMV2bUZxRyp6tFo8aL5hheV7UoaPKGlOxfgUNFv3U2uRUopVPH6uR1Z80
+JQoC2hDadI3wQ6/2egL62pQR3l/Ts8zF0sCFEGAZVrFklEneHsUS7PAbqIfY+TI
Ffc5q8Vm0QplWXr5vvxL1JKepXGgKSidMEnylAwIxKAnPtXyosPe1sZ+ocA+3gbP
Uj/bElWemX8b8YF/F1mecHqoLAvJ+3NKUdwS805VmdCLO1nxictKEOHAJFeQomif
OQquxdkcGtA9dmCt8JJ9
=SaUZ
-END PGP SIGNATURE-


-- 
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers

Re: [HACKERS] A little RLS oversight?

[Joe Conway]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

On 07/27/2015 10:03 AM, Joe Conway wrote:
 On 07/26/2015 07:59 AM, Joe Conway wrote:
 On 07/26/2015 07:19 AM, Dean Rasheed wrote:
 Attached is an updated patch (still needs some docs for the
 functions).
 
 Thanks for that. I'll add the docs.
 
 Documentation added. Also added comment to check_enable_rls about 
 passing InvalidOid versus GetUserId().
 
 I believe this is ready to go -- any other comments?

Strike that - now I really think it is ready to go :-)

In this patch I additionally changed instances of:
  check_enable_rls(indrelid, GetUserId(), true)
to
  check_enable_rls(indrelid, InvalidOid, true)
per Dean's earlier remark and my new comment.

- -- 
Joe Conway
-BEGIN PGP SIGNATURE-
Version: GnuPG v2.0.22 (GNU/Linux)

iQIcBAEBAgAGBQJVtma+AAoJEDfy90M199hl01wP+wYTV6VfBbpVEVf2+ZmbQlbJ
pgquLXkXsZ9vdsw/jY09+7HKwVQFjqq+E3zjqj/Pn9Q0h17cgflPuYSvde30Mb+l
86zVD5oKLttFlCb9Ablbauc8FoYTud3D+fJkGwDPBYh5VeIlFRwQMRSKQRxKHFfr
PvXmv3z7TmYGBe7dLEl24WyGncOtsJxPiHZDYA5Cna7lG+jlHqVIDz5itu6xGHgy
OOLfr07aZX3Bt9zmzg1NdxcBZNc6NkSVtKFzkqrJ+rCIcoMFxyIWsVp2IAEOItFI
o7hNEqrRk8yMcyX+Ej7K/6arOqCjQ6+RT+tJarCNDPv7WRXwt4PInircCjswt+uX
/vMM7zhzhrW+BMc2rbkU4TKfcEfI78SxUh3jKRTMbUWM6UJPZ+ca1mo6EQGNhUaS
mOMnpPD+huKXZpKlAC1ImH1boFPYqf9de6ToQRIdm7GKLUhKK8llWg3wC2GwMrtq
JDojJhPUohhofMaU7YjokJWx0vAa3NckgCO4nmYvL5Sc36+QUDlW4Amm43el7PvB
SkD2B0AvLZFmMJlrh3eAnuDleXzjRmVc1WoJtGGT2qwmL9oSDtT6y4Uh+0VnDJkh
T7XJ1NgvwFGNzG/heVTv346Mah2wRl/4A43jpojzQLjbNZ7t2gi8h9DkanA7/iGK
JOmMBbIfVlKnT+SKEOVJ
=WZhM
-END PGP SIGNATURE-
diff --git a/doc/src/sgml/func.sgml b/doc/src/sgml/func.sgml
index 98d1497..fd82ea4 100644
*** a/doc/src/sgml/func.sgml
--- b/doc/src/sgml/func.sgml
*** SET search_path TO replaceableschema/
*** 15259,15264 
--- 15259,15270 
 entrytypeboolean/type/entry
 entrydoes current user have privilege for role/entry
/row
+   row
+entryliteralfunctionrow_security_active/function(parametertable/parameter)/literal
+/entry
+entrytypeboolean/type/entry
+entrydoes current user have row level security active for table/entry
+   /row
   /tbody
  /tgroup
 /table
*** SET search_path TO replaceableschema/
*** 15299,15304 
--- 15305,15313 
 indexterm
  primarypg_has_role/primary
 /indexterm
+indexterm
+ primaryrow_security_active/primary
+/indexterm
  
 para
  functionhas_table_privilege/function checks whether a user
*** SELECT has_function_privilege('joeuser',
*** 15462,15467 
--- 15471,15483 
  are immediately available without doing commandSET ROLE/.
 /para
  
+para
+ functionrow_security_active/function checks whether row level
+ security is active for the specified table in the context of the
+ functioncurrent_user/function and environment. The table can
+ be specified by name or by OID.
+/para
+ 
para
 xref linkend=functions-info-schema-table shows functions that
 determine whether a certain object is firsttermvisible/ in the
diff --git a/src/backend/access/index/genam.c b/src/backend/access/index/genam.c
index 1043362..aa5b28c 100644
*** a/src/backend/access/index/genam.c
--- b/src/backend/access/index/genam.c
*** BuildIndexValueDescription(Relation inde
*** 204,210 
  	Assert(indexrelid == idxrec-indexrelid);
  
  	/* RLS check- if RLS is enabled then we don't return anything. */
! 	if (check_enable_rls(indrelid, GetUserId(), true) == RLS_ENABLED)
  	{
  		ReleaseSysCache(ht_idx);
  		return NULL;
--- 204,210 
  	Assert(indexrelid == idxrec-indexrelid);
  
  	/* RLS check- if RLS is enabled then we don't return anything. */
! 	if (check_enable_rls(indrelid, InvalidOid, true) == RLS_ENABLED)
  	{
  		ReleaseSysCache(ht_idx);
  		return NULL;
diff --git a/src/backend/catalog/system_views.sql b/src/backend/catalog/system_views.sql
index e82a53a..c0bd6fa 100644
*** a/src/backend/catalog/system_views.sql
--- b/src/backend/catalog/system_views.sql
*** CREATE VIEW pg_indexes AS
*** 150,156 
   LEFT JOIN pg_tablespace T ON (T.oid = I.reltablespace)
  WHERE C.relkind IN ('r', 'm') AND I.relkind = 'i';
  
! CREATE VIEW pg_stats AS
  SELECT
  nspname AS schemaname,
  relname AS tablename,
--- 150,156 
   LEFT JOIN pg_tablespace T ON (T.oid = I.reltablespace)
  WHERE C.relkind IN ('r', 'm') AND I.relkind = 'i';
  
! CREATE VIEW pg_stats WITH (security_barrier) AS
  SELECT
  nspname AS schemaname,
  relname AS tablename,
*** CREATE VIEW pg_stats AS
*** 211,217 
  FROM pg_statistic s JOIN pg_class c ON (c.oid = s.starelid)
   JOIN pg_attribute a ON (c.oid = attrelid AND attnum = s.staattnum)
   LEFT JOIN pg_namespace n ON (n.oid = c.relnamespace)
! WHERE NOT attisdropped AND has_column_privilege(c.oid, a.attnum, 'select');
  
  REVOKE ALL

Re: [HACKERS] A little RLS oversight?

[Joe Conway]

On 07/26/2015 07:59 AM, Joe Conway wrote:
 On 07/26/2015 07:19 AM, Dean Rasheed wrote:
 Attached is an updated patch (still needs some docs for the functions).
 
 Thanks for that. I'll add the docs.

Documentation added. Also added comment to check_enable_rls about
passing InvalidOid versus GetUserId().

I believe this is ready to go -- any other comments?

Joe

diff --git a/doc/src/sgml/func.sgml b/doc/src/sgml/func.sgml
index 98d1497..fd82ea4 100644
*** a/doc/src/sgml/func.sgml
--- b/doc/src/sgml/func.sgml
*** SET search_path TO replaceableschema/
*** 15259,15264 
--- 15259,15270 
 entrytypeboolean/type/entry
 entrydoes current user have privilege for role/entry
/row
+   row
+entryliteralfunctionrow_security_active/function(parametertable/parameter)/literal
+/entry
+entrytypeboolean/type/entry
+entrydoes current user have row level security active for table/entry
+   /row
   /tbody
  /tgroup
 /table
*** SET search_path TO replaceableschema/
*** 15299,15304 
--- 15305,15313 
 indexterm
  primarypg_has_role/primary
 /indexterm
+indexterm
+ primaryrow_security_active/primary
+/indexterm
  
 para
  functionhas_table_privilege/function checks whether a user
*** SELECT has_function_privilege('joeuser',
*** 15462,15467 
--- 15471,15483 
  are immediately available without doing commandSET ROLE/.
 /para
  
+para
+ functionrow_security_active/function checks whether row level
+ security is active for the specified table in the context of the
+ functioncurrent_user/function and environment. The table can
+ be specified by name or by OID.
+/para
+ 
para
 xref linkend=functions-info-schema-table shows functions that
 determine whether a certain object is firsttermvisible/ in the
diff --git a/src/backend/catalog/system_views.sql b/src/backend/catalog/system_views.sql
index e82a53a..c0bd6fa 100644
*** a/src/backend/catalog/system_views.sql
--- b/src/backend/catalog/system_views.sql
*** CREATE VIEW pg_indexes AS
*** 150,156 
   LEFT JOIN pg_tablespace T ON (T.oid = I.reltablespace)
  WHERE C.relkind IN ('r', 'm') AND I.relkind = 'i';
  
! CREATE VIEW pg_stats AS
  SELECT
  nspname AS schemaname,
  relname AS tablename,
--- 150,156 
   LEFT JOIN pg_tablespace T ON (T.oid = I.reltablespace)
  WHERE C.relkind IN ('r', 'm') AND I.relkind = 'i';
  
! CREATE VIEW pg_stats WITH (security_barrier) AS
  SELECT
  nspname AS schemaname,
  relname AS tablename,
*** CREATE VIEW pg_stats AS
*** 211,217 
  FROM pg_statistic s JOIN pg_class c ON (c.oid = s.starelid)
   JOIN pg_attribute a ON (c.oid = attrelid AND attnum = s.staattnum)
   LEFT JOIN pg_namespace n ON (n.oid = c.relnamespace)
! WHERE NOT attisdropped AND has_column_privilege(c.oid, a.attnum, 'select');
  
  REVOKE ALL on pg_statistic FROM public;
  
--- 211,219 
  FROM pg_statistic s JOIN pg_class c ON (c.oid = s.starelid)
   JOIN pg_attribute a ON (c.oid = attrelid AND attnum = s.staattnum)
   LEFT JOIN pg_namespace n ON (n.oid = c.relnamespace)
! WHERE NOT attisdropped
! AND has_column_privilege(c.oid, a.attnum, 'select')
! AND (c.relrowsecurity = false OR NOT row_security_active(c.oid));
  
  REVOKE ALL on pg_statistic FROM public;
  
diff --git a/src/backend/rewrite/rowsecurity.c b/src/backend/rewrite/rowsecurity.c
index aaf0061..2386cf0 100644
*** a/src/backend/rewrite/rowsecurity.c
--- b/src/backend/rewrite/rowsecurity.c
*** get_row_security_policies(Query *root, C
*** 107,113 
  
  	Relation	rel;
  	Oid			user_id;
- 	int			sec_context;
  	int			rls_status;
  	bool		defaultDeny = false;
  
--- 107,112 
*** get_row_security_policies(Query *root, C
*** 117,138 
  	*hasRowSecurity = false;
  	*hasSubLinks = false;
  
! 	/* This is just to get the security context */
! 	GetUserIdAndSecContext(user_id, sec_context);
  
  	/* Switch to checkAsUser if it's set */
  	user_id = rte-checkAsUser ? rte-checkAsUser : GetUserId();
  
- 	/*
- 	 * If this is not a normal relation, or we have been told to explicitly
- 	 * skip RLS (perhaps because this is an FK check) then just return
- 	 * immediately.
- 	 */
- 	if (rte-relid  FirstNormalObjectId
- 		|| rte-relkind != RELKIND_RELATION
- 		|| (sec_context  SECURITY_ROW_LEVEL_DISABLED))
- 		return;
- 
  	/* Determine the state of RLS for this, pass checkAsUser explicitly */
  	rls_status = check_enable_rls(rte-relid, rte-checkAsUser, false);
  
--- 116,128 
  	*hasRowSecurity = false;
  	*hasSubLinks = false;
  
! 	/* If this is not a normal relation, just return immediately */
! 	if (rte-relkind != RELKIND_RELATION)
! 		return;
  
  	/* Switch to checkAsUser if it's set */
  	user_id = rte-checkAsUser ? rte-checkAsUser

Re: [HACKERS] A little RLS oversight?

[Joe Conway]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

On 07/27/2015 01:25 PM, Dean Rasheed wrote:
 Looks good to me, except I'm not sure about those latest changes 
 because I don't understand the reasoning behind the logic in 
 check_enable_rls() when row_security is set to OFF.
 
 I would expect that if the current user has permission to bypass
 RLS, and they have set row_security to OFF, then it should be off
 for all tables that they have access to, regardless of how they
 access those tables (directly or through a view). If it really is
 intentional that RLS remains active when querying through a view
 not owned by the table's owner, then the other calls to
 check_enable_rls() should probably be left as they were, since the
 table might have been updated through such a view and that code
 can't really tell at that point.

After looking again at those three call sites, I'm now on the fence.
All three are in functions which are trying to avoid leaking info in
error messages. If we leave the original coding, then the messages
will remain the same for a given user regardless of the row_security
setting, whereas if we change them as in my latest patch, the messages
will be different depending on row_security for users with BYPASSRLS.

I think if we do the former (original coding) there should probably be
a comment added to indicate we are doing that intentionally.

Thoughts?

- -- 
Joe Conway
-BEGIN PGP SIGNATURE-
Version: GnuPG v2.0.22 (GNU/Linux)

iQIcBAEBAgAGBQJVtqRuAAoJEDfy90M199hlIQEQAIli3fJHPbpBBPocIjzo04EH
78YTiRYlb58ZK9l+VKj+sA9JbOdUVEes168hJjHSdnw6HcjJnKY+J3+aKjcRgXu2
s197hMOiP2+nqj0r0+KX/W8cuHT/4x5NtQ46BR9UoAPGdW9139CSbf3nQ9gTIllR
PQs7TRJIsJRWhuZhX5eCvQqix+RUYY2PKPMNdo8OLQpZxlsA7ezWr5QuDBx0PYFd
WTkaOsRxpAtfPBQrt+0xnX8oKi1pF4QLGt0Nb0J5XQmxUbKUdQsYY7+iu7Utrmf2
i5TORkX5HIpyH1N6R5Zu9wyRiOpLQv8SyH0kWovDA2neMlrApkM8kYfTYZAPIQUE
H6fOs6bafMMP4vWH7CwDhOwasccoLwdkEg80wiGnn5Nu+K4nq4k6Dq05oq+G7ZL1
6vZCXR0zts1TuX4abwtAcURaNbw+y7D/1XN9Dn0kDwuV3cXRh2tc33r/0SJ9XQFj
+gEdqptm3gyIgBExGlZDwNtpHwHEs2xqFjIBChyDV3cMjvFeTlYgiFiJlm40Ac/3
zelJ6hpsttAHWBg+42MoogrV7wKdCLOH/npwRx0zw5hH3meMs3ydQibtUwb/z+yl
6zl7xDMrTDOg/gV+gXbruVzSQIgNmfDEXmcHDKRr2IQwcNXXkTzEiIxJBRB7FhJg
GgXBUGlGDKRGXF8Koauy
=jCXT
-END PGP SIGNATURE-


-- 
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers

Re: [HACKERS] A little RLS oversight?

[Joe Conway]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

On 07/27/2015 03:05 PM, Stephen Frost wrote:
 AFK at the moment, but my thinking was that we should avoid having
 the error message change based on what a GUC is set to. I agree
 that there should be comments which explain that.

I changed back to using GetUserId() for the call to check_enable_rls()
at those three call sites, and added to the comments to explain why.

While looking at ri_ReportViolation() I spotted what I believe to be a
bug in the current logic -- namely, has_perm is initialized to true,
and when check_enable_rls() returns RLS_ENABLED we never reset
has_perm to false, and thus leak info even though the comments claim
we don't. I fixed that here, but someone please take a look and
confirm I am reading that correctly.

Beyond that, any additional comments?

Thanks,

Joe

- -- 
Joe Conway
-BEGIN PGP SIGNATURE-
Version: GnuPG v2.0.22 (GNU/Linux)

iQIcBAEBAgAGBQJVtuadAAoJEDfy90M199hl67kQAJw9iekYVAm52+kOxmBi8YLK
NMoRUWLv5AZ7coaltQBBTiYYbjWHVKoWaMrOg2OjtxjyeshYaZ+xsBQl4umznI9j
b2unSfUmRPcCgy7O6R63+IXePh6krKowlMAIkSelYjvV05nSgQfy87/xjcBXS12r
MajLambTyJycS8fQXdt9sG8uGZh7ncXUtip3mUOYgl9Omn5GiDcgbdV1xQR+GBRJ
48S9lTHIJenpvi83Y9/7CXfDwxdcvkziUkR67UL4jxqmjWBDrrGZWEWOE1KOn78W
dIvItOnuw/tKoxmhcwkgys+u92uhfQUUwhDQsJRVKsqzvPcVt6Oh15rtlqipbYEn
YfcM35Sa4sUtxL9JIoyof+8audagPy9nzD26c4jA2A7EWXHt8Dim/z7D5RgrOpdn
xBqlwViuR5Zt+kLynf3aZyDtmaMIRA+tvzJPam1vrl7g86LCJbZslFNktveiGeYl
17+PKLTDcVO5f6CdT1NTnlaks0J7D4VThxGemDs09KX6P8iCe6VFaUqfEONpjb41
WsumlDJkT9bu5i8W68xtEskXBYgBmDCo6yho4bKn/f6tpHc10yyh8RpK48P5xPt9
ZLSTLmYkfLL7wsINw6eNrQ4OZCtWwiydD9CmjQZOzscyBBusOvlIcI9Kfrle0I1V
r2gQN651WyY4YJIoEggu
=hlUr
-END PGP SIGNATURE-
diff --git a/doc/src/sgml/func.sgml b/doc/src/sgml/func.sgml
index 98d1497..fd82ea4 100644
*** a/doc/src/sgml/func.sgml
--- b/doc/src/sgml/func.sgml
*** SET search_path TO replaceableschema/
*** 15259,15264 
--- 15259,15270 
 entrytypeboolean/type/entry
 entrydoes current user have privilege for role/entry
/row
+   row
+entryliteralfunctionrow_security_active/function(parametertable/parameter)/literal
+/entry
+entrytypeboolean/type/entry
+entrydoes current user have row level security active for table/entry
+   /row
   /tbody
  /tgroup
 /table
*** SET search_path TO replaceableschema/
*** 15299,15304 
--- 15305,15313 
 indexterm
  primarypg_has_role/primary
 /indexterm
+indexterm
+ primaryrow_security_active/primary
+/indexterm
  
 para
  functionhas_table_privilege/function checks whether a user
*** SELECT has_function_privilege('joeuser',
*** 15462,15467 
--- 15471,15483 
  are immediately available without doing commandSET ROLE/.
 /para
  
+para
+ functionrow_security_active/function checks whether row level
+ security is active for the specified table in the context of the
+ functioncurrent_user/function and environment. The table can
+ be specified by name or by OID.
+/para
+ 
para
 xref linkend=functions-info-schema-table shows functions that
 determine whether a certain object is firsttermvisible/ in the
diff --git a/src/backend/access/index/genam.c b/src/backend/access/index/genam.c
index 1043362..2797c56 100644
*** a/src/backend/access/index/genam.c
--- b/src/backend/access/index/genam.c
*** BuildIndexValueDescription(Relation inde
*** 203,209 
  	indrelid = idxrec-indrelid;
  	Assert(indexrelid == idxrec-indexrelid);
  
! 	/* RLS check- if RLS is enabled then we don't return anything. */
  	if (check_enable_rls(indrelid, GetUserId(), true) == RLS_ENABLED)
  	{
  		ReleaseSysCache(ht_idx);
--- 203,213 
  	indrelid = idxrec-indrelid;
  	Assert(indexrelid == idxrec-indexrelid);
  
! 	/*
! 	 * RLS check - if RLS is enabled then we don't return anything.
! 	 * Explicitly pass GetUserId() to ensure the result is not
! 	 * dependent on the value of row_security for users with BYPASSRLS.
! 	 */
  	if (check_enable_rls(indrelid, GetUserId(), true) == RLS_ENABLED)
  	{
  		ReleaseSysCache(ht_idx);
diff --git a/src/backend/catalog/system_views.sql b/src/backend/catalog/system_views.sql
index e82a53a..c0bd6fa 100644
*** a/src/backend/catalog/system_views.sql
--- b/src/backend/catalog/system_views.sql
*** CREATE VIEW pg_indexes AS
*** 150,156 
   LEFT JOIN pg_tablespace T ON (T.oid = I.reltablespace)
  WHERE C.relkind IN ('r', 'm') AND I.relkind = 'i';
  
! CREATE VIEW pg_stats AS
  SELECT
  nspname AS schemaname,
  relname AS tablename,
--- 150,156 
   LEFT JOIN pg_tablespace T ON (T.oid = I.reltablespace)
  WHERE C.relkind IN ('r', 'm') AND I.relkind = 'i';
  
! CREATE VIEW pg_stats WITH (security_barrier) AS
  SELECT
  nspname AS schemaname,
  relname AS tablename,
*** CREATE VIEW pg_stats AS
*** 211,217

Re: [HACKERS] more RLS oversights

[Joe Conway]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

On 07/27/2015 01:13 PM, Alvaro Herrera wrote:
 Hmm, these are not ACL objects, so conceptually it seems cleaner to
 use a different symbol for this.  I think the catalog state and the
 error messages would be a bit confusing otherwise.

Ok -- done

 Isn't this leaking the previously allocated array?  Not sure it's
 all that critical, but still.  (I don't think you really need to
 call palloc at all here.)

Agreed -- I think the attached is a bit cleaner.

Any other comments or concerns?

- -- 
Joe Conway
-BEGIN PGP SIGNATURE-
Version: GnuPG v2.0.22 (GNU/Linux)

iQIcBAEBAgAGBQJVts3+AAoJEDfy90M199hlzTIQAJ6LEOrEEhHEjsoVvCT6TUAu
pMQl/LWmb0s3/vF9o5VFTpVd21k0LxcggD+DdbxSagiw1WpLK5x67C9Lj5uuFn/d
3a95nFnQje3ciQJaAKS4XcGyx8+6rHPZqfBRC1rARbLuDHrwpKqmbKwvpQCud4xN
kD7OolYk5Gd3cId0xH0XBHuwLVJg4Bt/MAexrcHn+kXuQoF8V6iOjnmBI/BHvTQy
w4j4ov7DpWSAR1ZiCTCkF2ZuNd9TJ8FmAEtSDVrlWMxB9J+9PU5oTfD50jp62BTz
wycANVYmbpCyZ7DAAiqopt3IQFIiF/1bYwzWH3/M8RRMKJF8HNyE8KBPDyC/doO5
0c0poCugJI2wOhumLGJShizgSAS85vqijh2Uxpp2yQxdStMnADykzT4Nb5EnEJVE
i7OKy6w+2xyilfFGEWhHfS7uo5Y0zBorhpjgT9fRaqPBGoK4jYwZoO8w97SUd9aS
kNXOCfmFxvcDFSZIYZP77pOeJZR2dLCbr+X9bF1Fz5S4FVkgCXVOp9rmsqzgxoDh
lcpkDh9zPPezdczRkfq/qCf0lmzGg8apdqdr7+g8DxU+01OvPspEdpovQQN0HXlM
m5Kbny4KCWhAgBTyAsOFTEy6lK7u4KsHV1cee3bG+ev65czbQ14gGRMJc/Lhm6Gg
Apcn/UcF14vLWxYVo6lS
=pS6L
-END PGP SIGNATURE-
diff --git a/doc/src/sgml/catalogs.sgml b/doc/src/sgml/catalogs.sgml
index 9096ee5..7781c56 100644
*** a/doc/src/sgml/catalogs.sgml
--- b/doc/src/sgml/catalogs.sgml
***
*** 5793,5798 
--- 5793,5808 
  /varlistentry
  
  varlistentry
+  termsymbolSHARED_DEPENDENCY_POLICY/ (literalr/)/term
+  listitem
+   para
+The referenced object (which must be a role) is mentioned as the
+target of a dependent policy object.
+   /para
+  /listitem
+ /varlistentry
+ 
+ varlistentry
   termsymbolSHARED_DEPENDENCY_PIN/ (literalp/)/term
   listitem
para
diff --git a/src/backend/catalog/pg_shdepend.c b/src/backend/catalog/pg_shdepend.c
index 34fe4e2..43076c9 100644
*** a/src/backend/catalog/pg_shdepend.c
--- b/src/backend/catalog/pg_shdepend.c
*** storeObjectDescription(StringInfo descs,
*** 1083,1088 
--- 1083,1090 
  appendStringInfo(descs, _(owner of %s), objdesc);
  			else if (deptype == SHARED_DEPENDENCY_ACL)
  appendStringInfo(descs, _(privileges for %s), objdesc);
+ 			else if (deptype == SHARED_DEPENDENCY_POLICY)
+ appendStringInfo(descs, _(target of %s), objdesc);
  			else
  elog(ERROR, unrecognized dependency type: %d,
  	 (int) deptype);
diff --git a/src/backend/commands/policy.c b/src/backend/commands/policy.c
index 17b48d4..9544f75 100644
*** a/src/backend/commands/policy.c
--- b/src/backend/commands/policy.c
***
*** 22,27 
--- 22,28 
  #include catalog/indexing.h
  #include catalog/namespace.h
  #include catalog/objectaccess.h
+ #include catalog/pg_authid.h
  #include catalog/pg_policy.h
  #include catalog/pg_type.h
  #include commands/policy.h
***
*** 48,54 
  static void RangeVarCallbackForPolicy(const RangeVar *rv,
  		  Oid relid, Oid oldrelid, void *arg);
  static char parse_policy_command(const char *cmd_name);
! static ArrayType *policy_role_list_to_array(List *roles);
  
  /*
   * Callback to RangeVarGetRelidExtended().
--- 49,55 
  static void RangeVarCallbackForPolicy(const RangeVar *rv,
  		  Oid relid, Oid oldrelid, void *arg);
  static char parse_policy_command(const char *cmd_name);
! static Datum *policy_role_list_to_array(List *roles, int *num_roles);
  
  /*
   * Callback to RangeVarGetRelidExtended().
*** parse_policy_command(const char *cmd_nam
*** 130,159 
  
  /*
   * policy_role_list_to_array
!  *	 helper function to convert a list of RoleSpecs to an array of role ids.
   */
! static ArrayType *
! policy_role_list_to_array(List *roles)
  {
! 	ArrayType  *role_ids;
! 	Datum	   *temp_array;
  	ListCell   *cell;
- 	int			num_roles;
  	int			i = 0;
  
  	/* Handle no roles being passed in as being for public */
  	if (roles == NIL)
  	{
! 		temp_array = (Datum *) palloc(sizeof(Datum));
! 		temp_array[0] = ObjectIdGetDatum(ACL_ID_PUBLIC);
  
! 		role_ids = construct_array(temp_array, 1, OIDOID, sizeof(Oid), true,
!    'i');
! 		return role_ids;
  	}
  
! 	num_roles = list_length(roles);
! 	temp_array = (Datum *) palloc(num_roles * sizeof(Datum));
  
  	foreach(cell, roles)
  	{
--- 131,158 
  
  /*
   * policy_role_list_to_array
!  *	 helper function to convert a list of RoleSpecs to an array of
!  *	 role id Datums.
   */
! static Datum *
! policy_role_list_to_array(List *roles, int *num_roles)
  {
! 	Datum	   *role_oids;
  	ListCell   *cell;
  	int			i = 0;
  
  	/* Handle no roles being passed in as being for public */
  	if (roles == NIL)
  	{
! 	   *num_roles = 1;
! 		role_oids = (Datum *) palloc(*num_roles * sizeof(Datum

Re: [HACKERS] more RLS oversights

[Joe Conway]

On 07/03/2015 10:03 AM, Noah Misch wrote:
 +static void
 +dumpPolicy(Archive *fout, PolicyInfo *polinfo)
 ...
 +if (polinfo-polqual != NULL)
 +appendPQExpBuffer(query,  USING %s, polinfo-polqual);
 
 (3) The USING clause needs parentheses; a dump+reload failed like so:

Also needed for WITH CHECK. Fix pushed to 9.5 and HEAD.

Joe




-- 
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers

Re: [HACKERS] A little RLS oversight?

[Joe Conway]

On 07/26/2015 07:19 AM, Dean Rasheed wrote:
 I'm not convinced about exporting convert_table_name() from acl.c,
 particularly with such a non-descriptive name. It's only a couple of
 lines of code, so I think they may as well just be included directly
 in the new function, as seems to be common practice elsewhere.

fair enough

 As it stands, passing checkAsUser = GetUserId() to check_enable_rls()
 will cause it to skip the check for row_security = OFF, and so it may
 falsely report that RLS is active when the user has bypassed it. To
 avoid that row_security_active() needs to pass checkAsUser =
 InvalidOid to check_enable_rls().

 [ Actually there seem to be a few other callers of check_enable_rls()
 that suffer the same problem. I don't really understand the reasoning
 behind that check in check_enable_rls() - if the current user has the
 BYPASSRLS attribute and row_security = OFF, shouldn't RLS be disabled
 on every table no matter how it is accessed? ]


Hmmm, I can see that now but find it surprising. Seems like an odd
interface, and probably deserves some explanation in the function
comments. Maybe Stephen or someone else can weigh in on this...


 I think it would be better if the security context check were part of
 this new function too. Right now that can't make any difference, since
 only the RI triggers set SECURITY_ROW_LEVEL_DISABLED and this function
 cannot be called in that code path, but it's possible that in the
 future other code might set SECURITY_ROW_LEVEL_DISABLED, so moving the
 check down guarantees that check_enable_rls()/row_security_active()
 always accurately return the RLS status for the table.
 
 While I was looking at it, I spotted a couple of other things to tidy
 up in existing related code:
 
 * The comment for GetUserIdAndSecContext() needed updating for the new RLS 
 bit.
 
 * Calling GetUserIdAndSecContext() and then throwing away the user_id
 returned seems ugly. There is already a code style precedent for
 checking the other bits of SecurityRestrictionContext, so I've added a
 similar bit-testing function for SECURITY_ROW_LEVEL_DISABLED which
 makes this code a bit neater.
 
 Attached is an updated patch (still needs some docs for the functions).

Thanks for that. I'll add the docs.

Joe





-- 
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers

Re: [HACKERS] more RLS oversights

[Joe Conway]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

On 07/03/2015 10:03 AM, Noah Misch wrote:
 (2) CreatePolicy() and AlterPolicy() omit to create a pg_shdepend
 entry for each role in the TO clause.  Test case:

Please see the attached patch. Note that I used SHARED_DEPENDENCY_ACL
for this. It seems appropriate, but possibly we should invent a new
shared dependency type for this use case? Comments?

Thanks,

Joe

-BEGIN PGP SIGNATURE-
Version: GnuPG v2.0.22 (GNU/Linux)

iQIcBAEBAgAGBQJVtSlAAAoJEDfy90M199hlrkIP/0BqMj30JpJVj3H5pIopU0RZ
pesBzFzzsWmt2QmasX9hajRfo6eXQAWPmKQmw/NDTJvHHNACxLdo0MHE7A9y7No7
aZIFTm0KhnG4jpzxfzpGqQ4ron5Vsc2TlNQgCBYCtbEEtuD0mV2qmcuTkqGte7iB
7iqneRBhmTYBy63X7S0ir4AhDi+JJg8P4F7YuU/XMcha5v5CpNJAToPpW7mCoZ8O
9w/RbXCHso7p1DIxfx4tfxVwLQ7j7G2j0rXbuA2e6OKfwZWWrk5E8Wnvc3xy3yCY
J37fcjOxFdhU/j1j+Tr90LYOSuRu5fQ4z6PmmsPkBM3T0Vllz/nNP64aVKbmHzga
szrIBERRs2icKa4OI08qZF42ObIEv0/t/NuyrXpegY6awRNNNsjyZvwM+51zdjw1
fuWh+2rObzh3RDH8lPB0N0rVfDMM+wU85Vaekckv/7UQ/pbWcwsYD/tykA1engQ8
Ww8kBAEct4dWdqppTqvLLxLgo4d+vuiS1mJ7SRY2aZFRX8QQ8TfB3eObETUsU4/X
9UWyMn+E0Au9ICX+wfD4whaBKst8EuO36qOZx0oZt+++EMOlzypgkCCxDtZO0KWd
KZHbtmJXHFVH+ihbEGXAKMIx+gLqSDG3IKy9MIJxpB3JY3XSdBNqobL2hiQy36/w
svK7i+mEYmUCQ6pB1j8c
=P1AS
-END PGP SIGNATURE-
diff --git a/src/backend/commands/policy.c b/src/backend/commands/policy.c
index 17b48d4..20ac54e 100644
*** a/src/backend/commands/policy.c
--- b/src/backend/commands/policy.c
***
*** 22,27 
--- 22,28 
  #include catalog/indexing.h
  #include catalog/namespace.h
  #include catalog/objectaccess.h
+ #include catalog/pg_authid.h
  #include catalog/pg_policy.h
  #include catalog/pg_type.h
  #include commands/policy.h
***
*** 48,54 
  static void RangeVarCallbackForPolicy(const RangeVar *rv,
  		  Oid relid, Oid oldrelid, void *arg);
  static char parse_policy_command(const char *cmd_name);
! static ArrayType *policy_role_list_to_array(List *roles);
  
  /*
   * Callback to RangeVarGetRelidExtended().
--- 49,55 
  static void RangeVarCallbackForPolicy(const RangeVar *rv,
  		  Oid relid, Oid oldrelid, void *arg);
  static char parse_policy_command(const char *cmd_name);
! static Datum *policy_role_list_to_array(List *roles, int *num_roles);
  
  /*
   * Callback to RangeVarGetRelidExtended().
*** parse_policy_command(const char *cmd_nam
*** 130,159 
  
  /*
   * policy_role_list_to_array
!  *	 helper function to convert a list of RoleSpecs to an array of role ids.
   */
! static ArrayType *
! policy_role_list_to_array(List *roles)
  {
! 	ArrayType  *role_ids;
! 	Datum	   *temp_array;
  	ListCell   *cell;
- 	int			num_roles;
  	int			i = 0;
  
  	/* Handle no roles being passed in as being for public */
  	if (roles == NIL)
  	{
! 		temp_array = (Datum *) palloc(sizeof(Datum));
! 		temp_array[0] = ObjectIdGetDatum(ACL_ID_PUBLIC);
  
! 		role_ids = construct_array(temp_array, 1, OIDOID, sizeof(Oid), true,
!    'i');
! 		return role_ids;
  	}
  
! 	num_roles = list_length(roles);
! 	temp_array = (Datum *) palloc(num_roles * sizeof(Datum));
  
  	foreach(cell, roles)
  	{
--- 131,158 
  
  /*
   * policy_role_list_to_array
!  *	 helper function to convert a list of RoleSpecs to an array of
!  *	 role id Datums.
   */
! static Datum *
! policy_role_list_to_array(List *roles, int *num_roles)
  {
! 	Datum	   *role_oids;
  	ListCell   *cell;
  	int			i = 0;
  
  	/* Handle no roles being passed in as being for public */
  	if (roles == NIL)
  	{
! 	   *num_roles = 1;
! 		role_oids = (Datum *) palloc(*num_roles * sizeof(Datum));
! 		role_oids[0] = ObjectIdGetDatum(ACL_ID_PUBLIC);
  
! 		return role_oids;
  	}
  
!*num_roles = list_length(roles);
! 	role_oids = (Datum *) palloc(*num_roles * sizeof(Datum));
  
  	foreach(cell, roles)
  	{
*** policy_role_list_to_array(List *roles)
*** 164,187 
  		 */
  		if (spec-roletype == ROLESPEC_PUBLIC)
  		{
! 			if (num_roles != 1)
  ereport(WARNING,
  		(errcode(ERRCODE_INVALID_PARAMETER_VALUE),
  		 errmsg(ignoring roles specified other than public),
  	  errhint(All roles are members of the public role.)));
! 			temp_array[0] = ObjectIdGetDatum(ACL_ID_PUBLIC);
! 			num_roles = 1;
! 			break;
  		}
  		else
! 			temp_array[i++] =
  ObjectIdGetDatum(get_rolespec_oid((Node *) spec, false));
  	}
  
! 	role_ids = construct_array(temp_array, num_roles, OIDOID, sizeof(Oid), true,
! 			   'i');
! 
! 	return role_ids;
  }
  
  /*
--- 163,187 
  		 */
  		if (spec-roletype == ROLESPEC_PUBLIC)
  		{
! 			Datum   *tmp_role_oids;
! 
! 			if (*num_roles != 1)
  ereport(WARNING,
  		(errcode(ERRCODE_INVALID_PARAMETER_VALUE),
  		 errmsg(ignoring roles specified other than public),
  	  errhint(All roles are members of the public role.)));
! 		   *num_roles = 1;
! 			tmp_role_oids = (Datum *) palloc(*num_roles * sizeof(Datum));
! 			tmp_role_oids[0] = ObjectIdGetDatum(ACL_ID_PUBLIC);
! 
! 			return tmp_role_oids;
  		}
  		else

Re: [HACKERS] markup problems in row_security GUC docs

[Joe Conway]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

On 07/25/2015 03:26 PM, Kevin Grittner wrote:
 The use of the apostrophe character to quote allowed enumerated 
 values seems wrong.  Probably these should be replaced by
 literal tags. The reference to BYPASSRLS also seems like it
 deserves markup, and possibly an entry in the index.  Does someone
 who is closer to the feature want to clean that up, or should I
 just do it?

I'll take care of it.

Joe

-BEGIN PGP SIGNATURE-
Version: GnuPG v2.0.22 (GNU/Linux)

iQIcBAEBAgAGBQJVtBjsAAoJEDfy90M199hluVYQAIEmSpSMuCIYRyzRDUTBdrsJ
jgJQIJG/OByEz126SXw6g1+965vFk8feOGSsqji1Naugw5QfYOCF95BN4UJqa6aP
T1pPQFR+Mrowyl121SzJiFIl4648sx5pIZ+bm1HNOqmkPAvZAJ2nXKKNankP4iBU
aHeDXpqCuNdONZqygvwQ3rP49ai7GYkYC+1ae0B0JshxetbFu8yvuOVlNGFi5aZ9
CmTr60Z2mPby8Mqx6s4FmBhfP7W9c3KuYSTM6CZqGlhRx4hiUCUil0/XsQun7Z+/
dTFuhzO+nuO+78X73lCLbRgQ+d1f35LJQfAGr8ObmyHg4hgxp6LMpNVzyc/d6Ffg
9LufcrR6eA9FvRB2CtVJlq88HNUUR31/F6XbZtBk97hsYB54NB4kI4/8cR2kHBQV
a+IekahAf4tbMK1wf5SIpNImvxAUKuduSEs9LJmSk5RuBsBink34YgmI6O11u7I2
btgQ6rWZ9lo+CV5bRn/vqtRCS06WNUEjjBM8jdntILxPIw/Pbc9OVkdb67kKBxFG
9mLPUQUPbdCi3wwGxmwvDA7f79G2fNI6QzGQP9Hzfdkz19hWvgz7R54ri9hh7hCI
oCbRm/bqRLOtrTnh3r8+Z4W/mMplYdNCE9YY3T+pXHi9zMiKs9UaHGg2q/SyPzS6
7NfEgabP0bzVKdqTXoVn
=l9GN
-END PGP SIGNATURE-


-- 
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers

Re: [HACKERS] A little RLS oversight?

[Joe Conway]

On 07/22/2015 02:17 PM, Dean Rasheed wrote:
 On 21 July 2015 at 04:53, Michael Paquier michael.paqu...@gmail.com wrote:
 On Tue, Jul 14, 2015 at 4:01 AM, Stephen Frost sfr...@snowman.net wrote:
 We need to be careful to avoid the slippery slope of trying to prevent
 all covert channels, which has been extensively discussed previously.
 
 I think this is more serious than the covert channel leaks discussed
 before, since most_common_vals explicitly reveals values from the
 table, making it an overt leak, albeit of a small portion of the
 table's values.
 
 Looking at that I am not seeing any straight-forward way to resolve
 this issue except by hardening pg_stats by having an additional filter
 of this type so as a non-owner of a relation cannot see the stats of
 this table directly when RLS is enabled:
 c.relrowsecurity = false OR c.relowner = current_user::regrole::oid
 Attached is a patch doing that (/me now hides, expecting to receive
 laser shots because of the use of current_user on a system view).
 Thoughts?
 
 Hmm, I think it probably ought to do more, based on whether or not RLS
 is being bypassed or in force-mode -- see the first few checks in
 get_row_security_policies(). Perhaps a new SQL-callable function
 exposing those checks and calling check_enable_rls(). It's probably
 still worth including the c.relrowsecurity = false check in SQL to
 save calling the function for the majority of tables that don't have
 RLS.

Please see the attached patch and let me know what you think. I believe
the only thing lacking is documentation for the two new user visible
functions. Comments?

Joe

diff --git a/src/backend/catalog/system_views.sql b/src/backend/catalog/system_views.sql
index e82a53a..c0bd6fa 100644
*** a/src/backend/catalog/system_views.sql
--- b/src/backend/catalog/system_views.sql
*** CREATE VIEW pg_indexes AS
*** 150,156 
   LEFT JOIN pg_tablespace T ON (T.oid = I.reltablespace)
  WHERE C.relkind IN ('r', 'm') AND I.relkind = 'i';
  
! CREATE VIEW pg_stats AS
  SELECT
  nspname AS schemaname,
  relname AS tablename,
--- 150,156 
   LEFT JOIN pg_tablespace T ON (T.oid = I.reltablespace)
  WHERE C.relkind IN ('r', 'm') AND I.relkind = 'i';
  
! CREATE VIEW pg_stats WITH (security_barrier) AS
  SELECT
  nspname AS schemaname,
  relname AS tablename,
*** CREATE VIEW pg_stats AS
*** 211,217 
  FROM pg_statistic s JOIN pg_class c ON (c.oid = s.starelid)
   JOIN pg_attribute a ON (c.oid = attrelid AND attnum = s.staattnum)
   LEFT JOIN pg_namespace n ON (n.oid = c.relnamespace)
! WHERE NOT attisdropped AND has_column_privilege(c.oid, a.attnum, 'select');
  
  REVOKE ALL on pg_statistic FROM public;
  
--- 211,219 
  FROM pg_statistic s JOIN pg_class c ON (c.oid = s.starelid)
   JOIN pg_attribute a ON (c.oid = attrelid AND attnum = s.staattnum)
   LEFT JOIN pg_namespace n ON (n.oid = c.relnamespace)
! WHERE NOT attisdropped
! AND has_column_privilege(c.oid, a.attnum, 'select')
! AND (c.relrowsecurity = false OR NOT row_security_active(c.oid));
  
  REVOKE ALL on pg_statistic FROM public;
  
diff --git a/src/backend/utils/adt/acl.c b/src/backend/utils/adt/acl.c
index 3ca168b..094ac33 100644
*** a/src/backend/utils/adt/acl.c
--- b/src/backend/utils/adt/acl.c
*** static AclMode convert_priv_string(text
*** 92,98 
  static AclMode convert_any_priv_string(text *priv_type_text,
  		const priv_map *privileges);
  
- static Oid	convert_table_name(text *tablename);
  static AclMode convert_table_priv_string(text *priv_type_text);
  static AclMode convert_sequence_priv_string(text *priv_type_text);
  static AttrNumber convert_column_name(Oid tableoid, text *column);
--- 92,97 
*** has_table_privilege_id_id(PG_FUNCTION_AR
*** 1998,2004 
  /*
   * Given a table name expressed as a string, look it up and return Oid
   */
! static Oid
  convert_table_name(text *tablename)
  {
  	RangeVar   *relrv;
--- 1997,2003 
  /*
   * Given a table name expressed as a string, look it up and return Oid
   */
! Oid
  convert_table_name(text *tablename)
  {
  	RangeVar   *relrv;
diff --git a/src/backend/utils/misc/rls.c b/src/backend/utils/misc/rls.c
index 44cb374..cd1a521 100644
*** a/src/backend/utils/misc/rls.c
--- b/src/backend/utils/misc/rls.c
***
*** 19,24 
--- 19,25 
  #include catalog/pg_class.h
  #include miscadmin.h
  #include utils/acl.h
+ #include utils/builtins.h
  #include utils/elog.h
  #include utils/rls.h
  #include utils/syscache.h
*** check_enable_rls(Oid relid, Oid checkAsU
*** 111,113 
--- 112,141 
  	/* RLS should be fully enabled for this relation. */
  	return RLS_ENABLED;
  }
+ 
+ /*
+  * row_security_active variants
+  *
+  * check_enable_rls wrapped as a SQL callable function except
+  * RLS_NONE_ENV and RLS_NONE are the same for this purpose.
+  */
+ Datum
+ 

Re: [HACKERS] markup problems in row_security GUC docs

[Joe Conway]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

On 07/25/2015 04:17 PM, Joe Conway wrote:
 On 07/25/2015 03:26 PM, Kevin Grittner wrote:
 The use of the apostrophe character to quote allowed enumerated 
 values seems wrong.  Probably these should be replaced by 
 literal tags. The reference to BYPASSRLS also seems like it 
 deserves markup, and possibly an entry in the index.  Does
 someone who is closer to the feature want to clean that up, or
 should I just do it?
 
 I'll take care of it.

I pushed a fix for this. There are no current index entries for
BYPASSRLS, so none added. Arguably there could be more improvements
with respect to index entries for RLS, but I'll save that for another
time.

- -- 
Joe Conway
-BEGIN PGP SIGNATURE-
Version: GnuPG v2.0.22 (GNU/Linux)

iQIcBAEBAgAGBQJVtC6bAAoJEDfy90M199hlow4QAJuQePEwM1t+3P8V+Qwt0a5P
sWL8i0UcEWIa6a/+s3SYZ+8j0QbXNdkruNNx+dYKrXMk5ZiicCfbvO/9FJeBRtW7
IjmXw6ootfg13uw4Rql4iOZLArSd7D1Lrb3T5NOTSkNktrNKLOfEPNrxps73H0rR
V5/TXfIcgLtWDvVA7k8RsUJt5uln/dw5n7JvpesncZqEEH2OQpSDOQZNJLxf83h+
gR0u6EFaWM7j9oQD0vVucqKCj3U+y93jwk5ZMEOeADUDw+ceM3FY/Pss5yLyIh7g
pySejFxmQavIuIKYapsACZwXg2Ro5Fs9QYErCwP3BBIk1277baMUYO+/NRnrwcFg
/VxehrkWC+JvFRlvVHeiIntwtKve0dhpcDxgl9ukbQ9mnYMmh4DoObjsSrusXLXQ
TX1XlCgI44QCqJ98qtje7r9cTUDVV0JgDkXJDeQ9YiWInsEXVkU560ioe+Ke09Fa
eof3X1FcR32TGFp7hEpSDs0EHZewd1eGae+4f3RdcANw0Gq14mmIs5sbxEaq9ip9
7+KP85O4jTAHIb6KgBbu80dAfyENjAh7v08UZixte1C+9rJ7wcXah63NxQV6QM24
6kWsVtPpImf4ZmSv4vF+Xi1wTOPkChGMzthz4lpwTt43ZdGE9xgBLJ3fwDGV/Vil
HaQyH6gX05LPuQ+usW86
=d3qv
-END PGP SIGNATURE-


-- 
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers

Re: [HACKERS] RLS fails to work with UPDATE ... WHERE CURRENT OF

[Joe Conway]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

On 07/14/2015 12:40 PM, Dean Rasheed wrote:
 On 14 July 2015 at 13:59, Robert Haas robertmh...@gmail.com
 wrote:
 On Thu, Jul 9, 2015 at 5:47 PM, Joe Conway m...@joeconway.com
 wrote:
 On 06/08/2015 02:08 AM, Dean Rasheed wrote:
 Actually I think it is fixable just by allowing the CURRENT
 OF expression to be pushed down into the subquery through
 the security barrier view. The planner is then guaranteed to
 generate a TID scan, filtering by any other RLS quals, which
 ought to be the optimal plan. Patch attached.
 
 This looks good to me. I have tested and don't find any issues
 with it. Will commit in a day or so unless someone has
 objections.
 
 Is this fix needed in all versions that support security barrier 
 views, or just in 9.5 and 9.6 that have RLS specifically?
 
 It's only needed in 9.5 and later for tables with RLS, because
 WHERE CURRENT OF isn't supported on views.

Pushed.


- -- 
Joe Conway
-BEGIN PGP SIGNATURE-
Version: GnuPG v2.0.22 (GNU/Linux)

iQIcBAEBAgAGBQJVspjUAAoJEDfy90M199hlJ3kP/i87ZlFmIOwApwm1y/OPOM/r
iW4BvUXadkbBnRG0ReoW9PPHXQHFbytunnL3I5Ddnnwa3KHFmzc7LBUpwRQRG5JO
bclB+Z/0AHYgdkKh/dvfngp2QddPk5bRZ2PuEYgMNBOFBWtANzOCdDVsKKouPnoq
0+H9o0LVWtInse8mL0J321Xl34XH0DKdeJSgG8Tq2Te7YCDkISLFQMv4jaOctktt
cfs1AYF1gG6ZoWjNDhupXejCIVR22VzONtjX3JxNWht3vhcN5bRBhU9KPZobfdaw
9cGbgIGHqZdb5ZZDILWbgiKvif/4krEDcnKLXHlsdnW4wO2oS7399d1Atjf7KJNX
unTX3yskYNcocGxIn76cGc76xWHoMj88AFxTlQ0zU3cUInZAQyFEK//4UiQ0Wzad
iAvTO4SwjyOY3/ipNlxKP0gwH27EA83mVZLiZ/qfo3GExD/NfI2rT2iGn7Dx9syX
frGFyYAm8cSWqVK+EzideL6yZL5fWoDpCC3GZnSHJEpriO/jnbqC0EmFxftP2N7N
1HSX8bjOExvLLtARry5SV6ngtu1gJABqRD38TjzExg/WMn+3S2NnYZHE3YGWpowz
CdSqLnVoGzHCNcj74eEV8XseX0JRVY3jHlv0iEme0MGmtkA1AdMesaUBjy9A9MGh
y2ZONUQCpBj/3lPj+wtb
=odS2
-END PGP SIGNATURE-


-- 
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers

Re: [HACKERS] more RLS oversights

[Joe Conway]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

On 07/10/2015 06:15 PM, Noah Misch wrote:
 On Fri, Jul 10, 2015 at 03:08:53PM -0700, Joe Conway wrote:
 On 07/03/2015 10:03 AM, Noah Misch wrote:
 (1) CreatePolicy() and AlterPolicy() omit to call
 assign_expr_collations() on the node trees.
 
 The attached fixes this issue for me, but I am unsure whether we
 really need/want the regression test. Given the recent push to
 increase test coverage maybe so.
 
 I wouldn't remove the test from your patch.
 

Ok -- pushed.

- -- 
Joe Conway
-BEGIN PGP SIGNATURE-
Version: GnuPG v2.0.22 (GNU/Linux)

iQIcBAEBAgAGBQJVoYj2AAoJEDfy90M199hleBcP/3anI8IIEkFyPiUDX0QvzfEM
EOBm+AdolwgAvscU6RaDbrVXJlE32YbSWsXhtXOA5jJvhY80ln3YO+ko1ONWV3dW
iYbvSO+zQalHDqmID2bqbnY/k+7GTGWPCTsSLMsmUK7P0QCVP2f02lCukqr4yWpH
tIVbOfb0A1+Mrb9dxta43Bj32maBBiEpWIwaebotik6BmfwHNeeaZ082PUJQvaqS
wtshrlctAaCsCyjQnNiPvtD9mw0rlSWOhNDc7R8KGflWnwXmBlyu7jD4aFHKcPZO
v1ErqG2Z0allm3p6snpFbiunQssVpHgF7V8FcWxIReu73lV25ig3Ix56MoUXHIOq
a2Y5iAfRw106V1GA6ARW0kjCaE0DrRcfA6/Um8LeEhw44cvUBZkhXx/ozt0t62pz
6mvhKN4UjmO/XfbA9GEN7b9kDz+LZtMFQ1PqcH7mK3OYKgGfYTAdJOA7qwHuWMBC
MGVHP5WEUCJEToTNyzVe0matOH8+IHS4LQ9qAtUFVCmhh27FK0m8kjoZAmT/xDk5
uNcMG9mvBOTZe5EmVdC1gywDOsRntzAgWM1SFBK2v0YEgj3YarKll839Jm+dNHGZ
nxjniR/XJkNxISrTN6Qq797nhYsmpqRg+d7ZVk0GxmhfNNp/f2SFRVB9/9ovrk4x
//7pllazs48qu6e/3eYK
=EEZ7
-END PGP SIGNATURE-


-- 
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers

Re: [HACKERS] more RLS oversights

[Joe Conway]

On 07/03/2015 10:03 AM, Noah Misch wrote:
 (1) CreatePolicy() and AlterPolicy() omit to call assign_expr_collations() on
 the node trees.  Test case:
 
 begin;
 set row_security = force;
 create table t (c) as values ('bar'::text);
 create policy p on t using (c  ('foo'::text COLLATE C));
 alter table t enable row level security;
 table pg_policy;  -- note :inputcollid 0
 select * from t;  -- ERROR:  could not determine which collation ...
 rollback;

The attached fixes this issue for me, but I am unsure whether we really
need/want the regression test. Given the recent push to increase test
coverage maybe so. Any objections?

Joe


diff --git a/src/backend/commands/policy.c b/src/backend/commands/policy.c
index 11efc9f..7232983 100644
*** a/src/backend/commands/policy.c
--- b/src/backend/commands/policy.c
*** CreatePolicy(CreatePolicyStmt *stmt)
*** 538,543 
--- 538,547 
  		   EXPR_KIND_WHERE,
  		   POLICY);
  
+ 	/* Fix up collation information */
+ 	assign_expr_collations(qual_pstate, qual);
+ 	assign_expr_collations(with_check_pstate, with_check_qual);
+ 
  	/* Open pg_policy catalog */
  	pg_policy_rel = heap_open(PolicyRelationId, RowExclusiveLock);
  
*** AlterPolicy(AlterPolicyStmt *stmt)
*** 681,686 
--- 685,693 
  	EXPR_KIND_WHERE,
  	POLICY);
  
+ 		/* Fix up collation information */
+ 		assign_expr_collations(qual_pstate, qual);
+ 
  		qual_parse_rtable = qual_pstate-p_rtable;
  		free_parsestate(qual_pstate);
  	}
*** AlterPolicy(AlterPolicyStmt *stmt)
*** 701,706 
--- 708,716 
  			   EXPR_KIND_WHERE,
  			   POLICY);
  
+ 		/* Fix up collation information */
+ 		assign_expr_collations(with_check_pstate, with_check_qual);
+ 
  		with_check_parse_rtable = with_check_pstate-p_rtable;
  		free_parsestate(with_check_pstate);
  	}
diff --git a/src/test/regress/expected/rowsecurity.out b/src/test/regress/expected/rowsecurity.out
index 4073c1b..eabfd93 100644
*** a/src/test/regress/expected/rowsecurity.out
--- b/src/test/regress/expected/rowsecurity.out
*** ERROR:  permission denied for relation c
*** 2730,2735 
--- 2730,2756 
  RESET SESSION AUTHORIZATION;
  DROP TABLE copy_t;
  --
+ -- Collation support
+ --
+ BEGIN;
+ SET row_security = force;
+ CREATE TABLE coll_t (c) AS VALUES ('bar'::text);
+ CREATE POLICY coll_p ON coll_t USING (c  ('foo'::text COLLATE C));
+ ALTER TABLE coll_t ENABLE ROW LEVEL SECURITY;
+ SELECT (string_to_array(polqual, ':'))[7] AS inputcollid FROM pg_policy WHERE polrelid = 'coll_t'::regclass;
+inputcollid
+ --
+  inputcollid 950 
+ (1 row)
+ 
+ SELECT * FROM coll_t;
+   c  
+ -
+  bar
+ (1 row)
+ 
+ ROLLBACK;
+ --
  -- Clean up objects
  --
  RESET SESSION AUTHORIZATION;
diff --git a/src/test/regress/sql/rowsecurity.sql b/src/test/regress/sql/rowsecurity.sql
index fdd9b89..782824a 100644
*** a/src/test/regress/sql/rowsecurity.sql
--- b/src/test/regress/sql/rowsecurity.sql
*** RESET SESSION AUTHORIZATION;
*** 1088,1093 
--- 1088,1105 
  DROP TABLE copy_t;
  
  --
+ -- Collation support
+ --
+ BEGIN;
+ SET row_security = force;
+ CREATE TABLE coll_t (c) AS VALUES ('bar'::text);
+ CREATE POLICY coll_p ON coll_t USING (c  ('foo'::text COLLATE C));
+ ALTER TABLE coll_t ENABLE ROW LEVEL SECURITY;
+ SELECT (string_to_array(polqual, ':'))[7] AS inputcollid FROM pg_policy WHERE polrelid = 'coll_t'::regclass;
+ SELECT * FROM coll_t;
+ ROLLBACK;
+ 
+ --
  -- Clean up objects
  --
  RESET SESSION AUTHORIZATION;

-- 
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers

Re: [HACKERS] dblink: add polymorphic functions.

[Joe Conway]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

On 07/07/2015 10:22 PM, Michael Paquier wrote:
 On Mon, Jul 6, 2015 at 11:52 PM, Joe Conway m...@joeconway.com
 wrote:
 That explains why the first example works while the second does
 not. I'm not sure how hard it would be to fix that, but it
 appears that that is where we should focus.
 
 Wouldn't it be fine if we drop some of the functions proposed
 without impacting the feature? Most of the functions overlap with
 each other, making us see the limitations we see.
 
 Hence, wouldn't it be enough to just have this set of functions in
 the patch? dblink_get_result(text, bool, anyelement) dblink (text,
 text, boolean, anyelement) dblink_fetch (text, text, int, boolean,
 anyelement)


I think new using function names is better especially if we are only
going to support a subset. I have no idea what to call them however.
Did someone else suggest dblink_any(), etc?

I also think that the ultimately best solution is (what I believe to
be spec compliant) SRF casting, but I guess that could be a task for a
later day.

- -- 
Joe Conway
-BEGIN PGP SIGNATURE-
Version: GnuPG v2.0.22 (GNU/Linux)

iQIcBAEBAgAGBQJVnT30AAoJEDfy90M199hl/dcP/29Byp5SE0TPE5EHeJwS6MDf
76KpsiyMZkxddBaiXiPbgrWEBZHdGExyzYj2qO9utPuFlzVTZpAbVcoFXaUg9Ak/
VMKkoxSB1iq1E1Pu64K26xvCU0GzMW1bazcGo4263iSlDjiRCB+CkL5UokEqSmvb
c9u7UZ3sdgn34C9iF3Z6pHa5GQoYB+i3kCxFuCdYMyHFZYdA0EtDvFNCoCNsWUCW
783IiQbeKCcj+j0bJ5v8lGfvHGfAJV0C0xiYiLios2nyClOvIQQQv2YN84BWDM6F
oWWJoExd51iL94RF/hRBJ/WXFFBfg/r30ULW5/dwhdp8cl1wPW+cY4srEHlTluZZ
KzoCujD5rhofJsS7tV9xs6tV4K/4/enknogHT0iWT89B/svAR52SUkRiH22mvhps
cpVVOsIP+ojmvmWW2p8jvq9ml5Ls6Z24AyRZ+OVZnVZGzAC9Z+NhwcjJaDWiWU2+
lgVuvIorYWZLHGzd6syrZKxKxdJRZ5ibYe2SN3Q2wlicZRPS5cXOgTfKoSduMTvY
GoNRPHQSPeuBNoq4pFUWN8EqH3oijN+PqdnIwc0HMaDyxR0AnISZiLwYWnY8WlqB
pdFV6tGsvsM6WbXTIqJ/3diRjRMl2/rtz6o8b3a1K7eL+PB7v5T0I+h9pwJQM2+a
WPffDIaY2Odnt9Axebu5
=CZ0t
-END PGP SIGNATURE-


-- 
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers

Re: [HACKERS] dblink: add polymorphic functions.

[Joe Conway]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

On 07/08/2015 08:51 AM, Corey Huinker wrote:
 Questions: Would moving rowtype to the first parameter resolve the
 parameter ambiguity issue?

Not for the existing functions but with new functions I don't think it
matters. You would know to always ignore either the first or last
argument when determining which variant was wanted.

 Would we want new function names anyway?

Yes, see above

 How much of a goal is reducing function count?

Do you mean reducing number of C functions or SQL functions?

 The following suffixes all make a degree of sense to me: _any() 
 _to_row() _to_rowtype() _to_recordset()-- borrowing from
 json[b]_to_recordsset() and json[b]_populate_recordset(), the first
 functions polymorphic functions to come to mind.
 
 IMO, _to_recordset() would win on POLA, and _any() would win on
 terse.

The problem is that jsonb_to_recordset() does not behave like these
new dblink functions in that it requires a runtime column definition
list. It might be better to use something completely different, so I
think _any() or maybe _to_any() is better.

Any other ideas for names out there?

Joe

- -- 
Joe Conway
-BEGIN PGP SIGNATURE-
Version: GnuPG v2.0.22 (GNU/Linux)

iQIcBAEBAgAGBQJVnU4kAAoJEDfy90M199hlxtIP/i9+ksY4Mq9lN0Ne+moLs3My
KY1lyQqXkynJpnbYArBPnmC8ejso/f9FpAfkoI8jA+YfzVLgN38aM/H5d6Kvpt2R
mA/Dpw7OpUrbZCsUT6JO7p0WRTqX2lNqX9FausgVXCTDXkYvKm3Vc3AgOUPVOfgv
BHuls6xlYtVbxJsQ3zm//sONwE6SmBexi6LWlzJiH3+UjfjYOEs2yj5aCObac+2+
2umrc3vfAPoCcXSEcMOwHYWBkwu1pxwtHrGObZYUt6pHCmNsj4o67AQv6z64x6fl
bRgvy/GOz2ict1DOs7kWha7Fvr9xC3FTyXxWaIpePo5mT92AzILp1L5+YgGZTxaA
jQISashYH5EAob7ow3hRJL2Gey7iQzgpHBClDlb/Tv4kDWV6BaBWaeQL2AUHEEGN
Y81hrQ6nsKnAQpPGUqvN0VHDUHn81S3T1SJZRptennGVqvuHrKwyVQj0yJo3wfcT
itnFZS2XmhNY11uVUZnZ0lZMClLn2jjedmNrfSHQPm+5EZBoW2B2QoXe/J/Oci1S
UEfl4IJyNgjAxYiG+7koAlo5DrxTPupVLWnoMxao+U71OOvU2Tzz6Jx/qV9+Rs2j
2web3tAKGyytRK/C+OO/dgjQsOdvR9D6lLp6l3GuC4q06KWe35bZuNJzACqQQaHj
7s3oZuTRKWqu4fHXW1om
=RxAo
-END PGP SIGNATURE-


-- 
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers

Re: [HACKERS] Improving regression tests to check LOCK TABLE and table permissions

[Joe Conway]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

On 05/11/2015 07:52 PM, Michael Paquier wrote:
 Hi all,
 
 As mentioned in this thread, it would be good to have regression
 tests to test the interactions with permissions and LOCK TABLE: 
 http://www.postgresql.org/message-id/20150511195335.ge30...@tamriel.sn
owman.net

 
Attached is a patch achieving that.
 Note that it does some checks on the modes SHARE ACCESS, ROW
 EXCLUSIVE and ACCESS EXCLUSIVE to check all the code paths of 
 LockTableAclCheck@lockcmds.c.
 
 I'll add an entry in the next CF to keep track of it. Regards,

Committed and pushed to master and 9.5

Joe

- -- 
Joe Conway
-BEGIN PGP SIGNATURE-
Version: GnuPG v2.0.22 (GNU/Linux)

iQIcBAEBAgAGBQJVnEcNAAoJEDfy90M199hlqTwP/0w87jIaAiJ86w+B72w24InP
77HYMqHd/6IB7cx6JWvDxeYZB0UN0h66A6z7TxaRyVCGM3m2ak73GwH+hj23TO9p
xCn94ZAFN4jfnFoiHAHQqThMlschbGFpvDbSxDyCbRyMV0t9ztpg+/bE/9/QZgg/
NzyhcjKQZZLhzMLDZva5i9jov8wi+cyVjYN2RT2I5+d7Sslrmz0QvOt8lCLMT6Mo
RQAMSy7m23SWCPjehDUhfaCvPu/Ur9E5PQx0JrJeSWGuJLbJ2Y700y7jstZYUgt9
96CmSJ1W/72deIzBWunf1eDFpLXqk3zn6Yi1K/wrGJwHDm7kfgqoSm5UsV9UYaE6
FUoPm3W2cqPXgOAzDJCfqS3mt7FOrYJ8dq+CsWK+eRRGmsjiOuNqu0YSAqC3rKUi
+GtBBXbaghm6+qLXi/ZSjfUdSq49Mj8jTMlWIcCxNWm7NV9lrXGUwRhCv97TrRoR
0Kl/PGL5Rsi9df2ck1VahEmIh5Ad+54I6On/0nZiq6pp42i7ZlrS1sA/kQbVLLVG
a1GPlXvN0pj8IGNyc2+FKdPBqTFrqp2Gcq2G4QfWWf5gCeTTyLKVtXPO8EcyJSGI
0Us+ELyW8IIBqCz/Rxh9T4NTPTsSlJbdpW8/vT9dY5z2rTR6IH11l+QQ2DOFDuM4
ehy/f/tjsT3u/VJIX79E
=3hyl
-END PGP SIGNATURE-


-- 
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers

Re: [HACKERS] Redundant error messages in policy.c

[Joe Conway]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

On 07/06/2015 02:26 PM, Stephen Frost wrote:
 Daniele,
 
 * Daniele Varrazzo (daniele.varra...@gmail.com) wrote:
 There are 5 different strings (one has a whitespace error), they 
 could be 2. Patch attached.
 
 Fair point.  I did try to address the language around policy vs. 
 row security vs. row level security, but didn't look as closely as 
 I should have at the error messages overall.
 
 Will address.

Pushed. Needed a small change to the expected regression output to match
.

Joe


- -- 
Joe Conway
-BEGIN PGP SIGNATURE-
Version: GnuPG v2.0.22 (GNU/Linux)

iQIcBAEBAgAGBQJVm9t6AAoJEDfy90M199hlcXgP+wbk8YhPdlt18rtKdxMWF7OW
B+D05Rf09st+PmnqsWUtTgMjuukEgc7yFQMMmYWj2AWjLaoLaYX6C+7lBQ0ZDsyh
Ye2G9e/GHfkNc99bDIQ4QOQZo9l0+y9evlWfu+LJVcb9Ai108F9hk9fFm2m4OG9p
k7Kj79XxXBqoni8PTiqJ7X29uX2i6Zd0Zkah0AR87B+IjgzJJrKKEWUqiehTRLbb
5wkjaTiHfad06Bs9R/guMKSDzTqihBaC2yd34zemlItbqn3Ib7pZCjTJaV1s1bOO
9tae1j/uymmBxIot3Ys0LxebCb6i3uGa5F4rEk1q0f7NIa9wSdfDPcBjIqDsn2WY
yRNYCbFtVNXj4ehYLeGuz3zkjMGFQzq+7dJPuKkuHUBB50LCt93yQyMbxQ4YB3Fq
OOWZUsxfYOJM4uW8BvSltbq0PSqyo/I4/SJe6yweJsgAXXlzS8EkxMC17vGdr457
ERCSlxXESJ/+tL35GMiujsgSbQZMUu+fxe6bcH3zT4c1nbS8dEpHMm4G+Nojq6b8
pL9sB8txKc0utjVg63nb3oF3hPC25gXk9DHC8bOVUkp77o2TjhroixKvuTN+to+o
JLMseH06s7ZU69b8QNu1YtkeLPxOKZ7INHXSAZ6a2uXaRgNr8nMtJF+mSV0i9XlK
a1e9wR6QBq81PUMiZURN
=LgG6
-END PGP SIGNATURE-


-- 
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers