[HACKERS] Out of date docs: DISABLE/ENABLE TRIGGER
Hi, I just spotted that the docs for ALTER TABLE .. DISABLE/ENABLE TRIGGER are out of date, now that we have deferrable uniqueness and exclusion constraints. Also, I think that the original comment in the ENABLE/DISABLE TRIGGER section was misleading because it suggested that only superusers can disable constraint triggers, which is not true for *user-defined* constraint triggers. Proposed update attached. Regards, Dean alter_table_docs.patch Description: Binary data -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
[HACKERS] SR slaves and .pgpass
The docs state, w.r.t. $subject: The password can be provided either in the primary_conninfo string or in a separate ~/.pgpass file on the standby server. I tried this with a database name of "replication" in the .pgpass file, which matches what we need to use in pg_hba.conf, but it failed miserably, and only worked when I used a wildcard for the database name in the .pgpass file. If this is expected it needs to be documented more clearly; if not, it's a bug. I expect this to be quite a common thing to do - many people will be like me and dislike putting passwords in config files. cheers andrerw -- 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] Fix leaky VIEWs for RLS
On Fri, Jun 4, 2010 at 4:12 PM, Tom Lane wrote: > Heikki Linnakangas writes: >> On 04/06/10 22:33, Tom Lane wrote: >>> A counterexample: suppose we had a form of type "text" that carried a >>> collation specifier internally, and the comparison routine threw an >>> error if asked to compare values with incompatible specifiers. An index >>> built on a column of all the same collation would work fine. A query >>> that tried to compare against a constant of a different collation would >>> throw an error. > >> I can't take that example seriously. First of all, tacking a collation >> specifier to text values would be an awful hack. > > Really? I thought that was under serious discussion. But whether it > applies to text or not is insignificant; I believe there are cases just > like this in existence today for some datatypes (think postgis). > > The real point is that the comparison constant is under the control of > the attacker, and it's not part of the index. Therefore "it didn't > throw an error during index construction" proves nothing whatever. > >> ... Secondly, it would be a >> bad idea to define the b-tree comparison operators to throw an error; > > You're still being far too trusting, by imagining that only *designed* > error conditions matter here. Think about overflows, out-of-memory, > (perhaps intentionally) corrupted data, etc etc. btree comparison operators should handle overflow and corrupted data without blowing up. Maybe out-of-memory is worth worrying about, but I think that is a mighty thin excuse for abandoning this feature altogether. You'd have to contrive a situation where the system was just about out of memory and something about the value being compared against resulted in the comparison blowing up or not. I think that's likely to be rather hard in practice, and in any case it's a covert channel attack, which I think everyone already agrees is beyond the scope of what we can protect against. You can probably learn more information more quickly about the unseen data by fidding with EXPLAIN, analyzing query execution times, etc. As long as we are preventing the actual contents of the unseen tuples from being revealed, I feel reasonably good about it. > I think the only real fix would be something like what Marc suggested: > if there's a security view involved in the query, we simply don't give > the client the real error message. Of course, now our "security > feature" is utterly disastrous on usability as well as performance > counts ... Not pushing anything into the view is an equally real fix, although I'll be pretty depressed if that's where we end up. -- Robert Haas EnterpriseDB: http://www.enterprisedb.com The Enterprise Postgres Company -- 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] nvarchar notation accepted?
On Thu, May 13, 2010 at 11:00 PM, Tom Lane wrote: > Jaime Casanova writes: >> On Thu, May 13, 2010 at 10:52 PM, Tom Lane wrote: >>> Actually, the lexer translates N'foo' to NCHAR 'foo' and then the >>> grammar treats that just like CHAR 'foo'. In short, the N doesn't do >>> anything very useful, and it certainly doesn't have any effect on >>> encoding behavior. I think this is something Tom Lockhart put in ten or >>> so years back, and never got as far as making it actually do anything >>> helpful. > >> so, the N'' syntax is fine and i don't need to hunt them as a migration step? > > As long as the implied cast to char(n) doesn't cause you problems, it's > fine. > Is this something we want to document? Maybe something like: """ For historical reasons N'' syntax is also accepted as a string literal. """ or we can even mention the fact that that is useful for sql server migrations? -- Jaime Casanova www.2ndQuadrant.com Soporte y capacitación de PostgreSQL -- 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] Fix leaky VIEWs for RLS
* Robert Haas (robertmh...@gmail.com) wrote: > Another idea I had was... would it be safe to trust functions defined > by the same user who owns the view? If he's granted access to the > view and the function to some other user, presumably he doesn't mind > them being used together? Or is that too optimistic? This was more-or-less what I'd been kind of kicking around in my head. Forget about functions that are defined in the view itself. Any other functions, etc, which are attached to the view by the calling user would be suspect, etc. Perhaps with the exception of some built-ins that we've marked as "safe" in some way. My first thought was to track the "run this as X" information on every RTE (more-or-less, relations, function calls, etc) and then at least be able to, hopefully, *detect* situations that might be a problem- eg: running a function which has "run as Q" against a relation that was accessed as "run as R" when a filter "run as R" happens later. This is all far too hand-wavey, I'm sure, but at least if we could detect it then we might be able to find a way to deal with it. Also, perhaps I'm not being paranoid enough, but all this concern over error cases really doesn't really worry me that much. The amount of data one could acquire that way is pretty limited. It'd be great if we could deal with that case too, but maybe we could worry about the bigger issue (at least, as I see it) first. Just my 2c. Thanks, Stephen signature.asc Description: Digital signature
[HACKERS] ps display "waiting for max_standby_delay"
Hi, We have codes to change ps display for recovery process during hot standby. The current code always shows max_standby_delay for the message, but how about showing actual waiting time instead? Since DBAs can always get the parameter from postgresql.conf they wrote, so the parameter value itself is not so useful. Actual waiting time might be more useful to determine which values to be set to max_standby_delay, no? [backend/storage/ipc/standby.c] snprintf(new_status + len, 50, " waiting for max_standby_delay (%d ms)", MaxStandbyDelay); ==> GetCurrentTimestamp() - waitStart set_ps_display(new_status, false); I think SQL-based activity view will be more useful than ps display, but it's an item for 9.1. Regards, --- Takahiro Itagaki NTT Open Source Software Center -- 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] Fix leaky VIEWs for RLS
(2010/06/07 10:38), Robert Haas wrote: > On Fri, Jun 4, 2010 at 4:12 PM, Tom Lane wrote: >> Heikki Linnakangas writes: >>> On 04/06/10 22:33, Tom Lane wrote: A counterexample: suppose we had a form of type "text" that carried a collation specifier internally, and the comparison routine threw an error if asked to compare values with incompatible specifiers. An index built on a column of all the same collation would work fine. A query that tried to compare against a constant of a different collation would throw an error. >> >>> I can't take that example seriously. First of all, tacking a collation >>> specifier to text values would be an awful hack. >> >> Really? I thought that was under serious discussion. But whether it >> applies to text or not is insignificant; I believe there are cases just >> like this in existence today for some datatypes (think postgis). >> >> The real point is that the comparison constant is under the control of >> the attacker, and it's not part of the index. Therefore "it didn't >> throw an error during index construction" proves nothing whatever. >> >>> ... Secondly, it would be a >>> bad idea to define the b-tree comparison operators to throw an error; >> >> You're still being far too trusting, by imagining that only *designed* >> error conditions matter here. Think about overflows, out-of-memory, >> (perhaps intentionally) corrupted data, etc etc. > > btree comparison operators should handle overflow and corrupted data > without blowing up. Maybe out-of-memory is worth worrying about, but > I think that is a mighty thin excuse for abandoning this feature > altogether. You'd have to contrive a situation where the system was > just about out of memory and something about the value being compared > against resulted in the comparison blowing up or not. I think that's > likely to be rather hard in practice, and in any case it's a covert > channel attack, which I think everyone already agrees is beyond the > scope of what we can protect against. You can probably learn more > information more quickly about the unseen data by fidding with > EXPLAIN, analyzing query execution times, etc. As long as we are > preventing the actual contents of the unseen tuples from being > revealed, I feel reasonably good about it. > It seems to me a good point. In general, any software have possibility to leak information via cover-channels, and it is nearly impossible to fix all the channels. However, from a security perspective, covert channels with low bandwidths represent a lower threat than those with high bandwidths. So, evaluation criteria stands on the viewpoint that it does not necessary to eliminate all the covert channels more than necessity. Even if we can estimate the contents of invisible tuples from error messages or EXPLAIN output, its bandwidths are quite limited. But, lowrite() might write out the given argument somewhere, if it is invoked prior to security policy functions. In this case, the contents of invisible tuples will be moved to another large object unexpectedly with unignorable speed. Such a direct data flow channel should be fixed at first, because of its large bandwidth. >> I think the only real fix would be something like what Marc suggested: >> if there's a security view involved in the query, we simply don't give >> the client the real error message. Of course, now our "security >> feature" is utterly disastrous on usability as well as performance >> counts ... > > Not pushing anything into the view is an equally real fix, although > I'll be pretty depressed if that's where we end up. > I could not find out any certified commercial RDBMS with functionality to tackle covert channel. It includes Oracle's row-level security stuff. So, I don't think it is our goal to prevent anything into views. An idea is that we focus on the direct data flow which allows to move information to be invisible into another tables, files and so on. In this stage, I don't think the priority of error messages are high. Thanks, -- KaiGai Kohei -- 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] Fix leaky VIEWs for RLS
(2010/06/07 12:06), Stephen Frost wrote: > * Robert Haas (robertmh...@gmail.com) wrote: >> Another idea I had was... would it be safe to trust functions defined >> by the same user who owns the view? If he's granted access to the >> view and the function to some other user, presumably he doesn't mind >> them being used together? Or is that too optimistic? > > This was more-or-less what I'd been kind of kicking around in my head. > Forget about functions that are defined in the view itself. Any other > functions, etc, which are attached to the view by the calling user would > be suspect, etc. Perhaps with the exception of some built-ins that > we've marked as "safe" in some way. > > My first thought was to track the "run this as X" information on every > RTE (more-or-less, relations, function calls, etc) and then at least be > able to, hopefully, *detect* situations that might be a problem- eg: > running a function which has "run as Q" against a relation that was > accessed as "run as R" when a filter "run as R" happens later. This is > all far too hand-wavey, I'm sure, but at least if we could detect it > then we might be able to find a way to deal with it. > It is a similar idea to what I tried to implement at the conceptual patch. It checks privileges of calling user on the underlaying tables to be referenced using views. If violated, it prevents to push down the user given FuncExpr into join loops of views. Otherwise, it does not prevent anything, because the user originally has privileges to reference them. Are you suggesting the idea (with adjustments such as "safe" functions)? > Also, perhaps I'm not being paranoid enough, but all this concern over > error cases really doesn't really worry me that much. The amount of > data one could acquire that way is pretty limited. It'd be great if we > could deal with that case too, but maybe we could worry about the bigger > issue (at least, as I see it) first. > As I also mentioned at previous message. It seems to me a good point to focus on bandwidth of the covert channel. The error message indeed can deliver information to be invisible, but I don't think its priority is higher than functions that can be abused to direct data flow channel, such as lowrite(). Thanks, -- KaiGai Kohei -- 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] SR slaves and .pgpass
On Mon, Jun 7, 2010 at 5:42 AM, Andrew Dunstan wrote: > > The docs state, w.r.t. $subject: > > The password can be provided either in the primary_conninfo string > or in a separate ~/.pgpass file on the standby server. > > I tried this with a database name of "replication" in the .pgpass file, > which matches what we need to use in pg_hba.conf, but it failed miserably, > and only worked when I used a wildcard for the database name in the .pgpass > file. > > If this is expected it needs to be documented more clearly; if not, it's a > bug. Yep, this is expected, so we need to improve the doc. What about: diff --git a/doc/src/sgml/high-availability.sgml b/doc/src/sgml/high-availability.sgml index 5c0d9ab..458a4e2 100644 --- a/doc/src/sgml/high-availability.sgml +++ b/doc/src/sgml/high-availability.sgml @@ -819,7 +819,9 @@ hostreplication foo 192.168.1.100/32md5 The host name and port number of the primary, connection user name, and password are specified in the recovery.conf file or - the corresponding environment variable on the standby. + in a separate ~/.pgpass on the standby (In the latter case, + database field in a ~/.pgpass file must be + *). For example, if the primary is running on host IP 192.168.1.50, port 5432, the superuser's name for replication is foo, and the password is foopass, the administrator diff --git a/doc/src/sgml/recovery-config.sgml b/doc/src/sgml/recovery-config.sgml index 439db3f..cc351f8 100644 --- a/doc/src/sgml/recovery-config.sgml +++ b/doc/src/sgml/recovery-config.sgml @@ -268,9 +268,11 @@ restore_command = 'copy "C:\\server\\archivedir\\%f" "%p"' # Windows primary (see ). A password needs to be provided too, if the primary demands password - authentication. (The password can be provided either in + authentication. The password can be provided either in the primary_conninfo string or in a separate - ~/.pgpass file on the standby server.) + ~/.pgpass file on the standby server (in the latter case, + database field in a ~/.pgpass file must be + *). Do not specify a database name in the primary_conninfo string. Regards, -- Fujii Masao NIPPON TELEGRAPH AND TELEPHONE CORPORATION NTT Open Source Software Center -- 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] Fix leaky VIEWs for RLS
On 07/06/10 06:06, Stephen Frost wrote: Also, perhaps I'm not being paranoid enough, but all this concern over error cases really doesn't really worry me that much. The amount of data one could acquire that way is pretty limited. It's not limited. It allows you to read all contents of the underlying table or tables. I don't see much point doing anything at all if we don't plug that. There's many side channels like exposing row counts in EXPLAIN and statistics and timing attacks, that are not as critical, because they don't let expose all data, and the attacker can't accurately choose what data is exposed. Those are not as important. -- Heikki Linnakangas EnterpriseDB http://www.enterprisedb.com -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
