Re: CREATE FUNCTION ... SEARCH { DEFAULT | SYSTEM | SESSION }

hema qualifying of one's own functions), but agree that almost no one wants that for the latter (needing to schema qualify every table reference). Should there be a way to have a separate "execution" search_path? -- Joe Conway PostgreSQL Contributors Team RDS Open Sou

Re: CREATE FUNCTION ... SEARCH { DEFAULT | SYSTEM | SESSION }

On 9/25/23 14:03, Jeff Davis wrote: On Mon, 2023-09-25 at 12:00 -0400, Joe Conway wrote: Should there be a way to have a separate "execution" search_path? I hadn't considered that and I like that idea for a few reasons: * a lot of the problem cases are for functions tha

commitfest app down for repairs

The committfest app is down for repairs. We will reply back here once it is back up. -- Joe Conway PostgreSQL Contributors Team RDS Open Source Databases Amazon Web Services: https://aws.amazon.com

Re: commitfest app down for repairs

On 9/30/23 08:47, Joe Conway wrote: The committfest app is down for repairs. We will reply back here once it is back up. The commitfest app is back up. We restored to a backup from one day prior. We will take a look at what changed in between, but it might be up to folks to redo some things

Re: pg_config wrongly marked as not parallel safe?

On 11/30/18 10:32 AM, Tom Lane wrote: > Joe Conway writes: >> On 11/30/18 3:30 AM, Kyotaro HORIGUCHI wrote: >>> # And returning to the topic, I vote for pg_config should be "stable". > >> And on that note, Does this change does warrant backpatching, or should

Re: Some thoughts on NFS

On 2/19/19 10:59 AM, Magnus Hagander wrote: > On Tue, Feb 19, 2019 at 4:46 PM Robert Haas > wrote: > > On Tue, Feb 19, 2019 at 2:03 AM Thomas Munro > wrote: > > How can we achieve that, without writing our > > own NFS c

Re: Row Level Security − leakproof-ness and performance implications

On 2/19/19 6:43 PM, Laurenz Albe wrote: > Pierre Ducroquet wrote: >> if we had a 'RLS-enabled' context on functions, a way to make a lot of built- >> in functions leakproof would simply be to prevent them from logging errors >> containing values. >> >> For others, like arraycontains, it's much tr

Re: list append syntax for postgresql.conf

On 2/20/19 10:15 AM, Peter Eisentraut wrote: > Nowadays there are a number of methods for composing multiple > postgresql.conf files for modularity. But if you have a bunch of things > you want to load via shared_preload_libraries, you have to put them all > in one setting. How about some kind of

Re: BUG #15646: Inconsistent behavior for current_setting/set_config

On 2/20/19 12:11 PM, Tom Lane wrote: > Joe Conway writes: >> On 2/20/19 11:10 AM, PG Bug reporting form wrote: >>> But current behavior returns empty string instead of NULL (the initial >>> value) after transaction is rolled back. When I restart session, NULL is

Re: [PATCH v20] GSSAPI encryption support

On 4/2/19 6:18 PM, Stephen Frost wrote: > Greetings, > > On Tue, Apr 2, 2019 at 18:10 Peter Eisentraut > > wrote: > > On 2019-02-23 17:27, Stephen Frost wrote: > >> About pg_hba.conf: The "hostgss" keyword seems a bit confusing.  > It only >

Re: Should the docs have a warning about pg_stat_reset()?

On 4/13/19 3:42 PM, Tomas Vondra wrote: > If only we had a way to regularly snapshot the data from within the > database, and then compute the deltas on that. If only we could insert > data from one table into another one a then do some analysics on it, > with like small windows moving over the dat

TRACE_SORT defined by default

I just noticed that TRACE_SORT is defined by default (since 2005 apparently). It seems odd since it is the only debugging code enabled by default. Joe -- Crunchy Data - http://crunchydata.com PostgreSQL Support for Secure Enterprises Consulting, Training, & Open Source Development signature.a

Re: TRACE_SORT defined by default

On 4/24/19 5:10 PM, Peter Geoghegan wrote: > On Wed, Apr 24, 2019 at 2:07 PM Joe Conway wrote: >> I just noticed that TRACE_SORT is defined by default (since 2005 >> apparently). It seems odd since it is the only debugging code enabled by >> default. > > I think th

Re: How to install login_hook in Postgres 10.5

On 5/13/19 8:32 PM, Michael Paquier wrote: > On Mon, May 13, 2019 at 01:06:10PM -0700, legrand legrand wrote: >> that finished commited >> "pgsql: Add hooks for session start and session end" >> https://www.postgresql.org/message-id/flat/575d6fa2-78d0-4456-8600-302fc35b2591%40dunslane.net#0819e315c

stawidth inconsistency with all NULL columns

Consider: CREATE TABLE testwid ( txtnotnull text, txtnull text, int8notnull int8, int8null int8 ); INSERT INTO testwid SELECT 'a' || g.i, NULL, g.i, NULL FROM generate_series(1,1) AS g(i); ANALYZE testwid; SELECT attname, avg_width FROM pg_stats WHERE tablename = '

Re: stawidth inconsistency with all NULL columns

On 5/21/19 3:55 PM, Tom Lane wrote: > Joe Conway writes: >> else if (null_cnt > 0) >> { >> /* We found only nulls; assume the column is entirely null */ >> stats->stats_valid = true; >> stats->stanullfrac = 1.0; >> if (is_varwidth

Re: initdb recommendations

On 5/23/19 10:30 PM, Stephen Frost wrote: > Greetings, > > * Tom Lane (t...@sss.pgh.pa.us) wrote: >> "Jonathan S. Katz" writes: >> > For now I have left in the password based method to be scram-sha-256 as >> > I am optimistic about the support across client drivers[1] (and FWIW I >> > have an imp

Re: initdb recommendations

On 5/24/19 8:13 AM, Stephen Frost wrote: > Greetings, > > * Joe Conway (m...@joeconway.com) wrote: >> On 5/23/19 10:30 PM, Stephen Frost wrote: >> > * Tom Lane (t...@sss.pgh.pa.us) wrote: >> >> "Jonathan S. Katz" writes: >> >> > For

Re: Excessive memory usage in multi-statement queries w/ partitioning

On 5/24/19 1:47 AM, Amit Langote wrote: > On 2019/05/23 4:15, Andreas Seltenreich wrote: >> …but when doing it on the parent relation, even 100 statements are >> enough to exceed the limit: >> >> , >> | $ psql -c "$(yes update t set c=c where c=6 \; | head -n 100)" >> | FEHLER: Speicher aufge

Re: initdb recommendations

On 5/24/19 8:56 AM, Jonathan S. Katz wrote: > On 5/24/19 8:33 AM, Stephen Frost wrote: >> * Magnus Hagander (mag...@hagander.net) wrote: >>> Making the default change away from trust in the source distro will affect >>> few people. >> >> Agreed. > > +1 Fewer people, but likely disproportionately

Re: Excessive memory usage in multi-statement queries w/ partitioning

On 5/24/19 9:33 AM, David Rowley wrote: > On Sat, 25 May 2019 at 00:18, Joe Conway wrote: >> I admittedly haven't followed this thread too closely, but if having 100 >> partitions causes out of memory on pg11, that sounds like a massive >> regression to me. > > F

Re: Excessive memory usage in multi-statement queries w/ partitioning

On 5/24/19 10:28 AM, Tom Lane wrote: > Joe Conway writes: >> On 5/24/19 9:33 AM, David Rowley wrote: >>> For it to have regressed it would have had to once have been better, >>> but where was that mentioned? The only thing I saw was >>> non-partitioned tables

Re: New committer: David Rowley

On 5/30/19 11:43 AM, Andres Freund wrote: > Hi, > > On 2019-05-30 11:39:23 -0400, Magnus Hagander wrote: >> For those of you that have not read the minutes from the developer meeting >> ahead of pgcon (can be found at >> https://wiki.postgresql.org/wiki/PgCon_2019_Developer_Meeting), we'd like >>

assert in nested SQL procedure call in current HEAD

My colleague Yogesh Sharma discovered an assert in nested SQL procedure calls after ROLLBACK is used. Minimal test case and backtrace below. I have not yet tried to figure out exactly what is going on beyond seeing that it occurs in pg_plan_query() where the comment says "Planner must have a snapsh

Re: Redesigning the executor (async, JIT, memory efficiency)

On 05/24/2018 11:26 PM, Heikki Linnakangas wrote: > Cool stuff! > > On 25/05/18 06:35, Andres Freund wrote: >> For example, this converts this converts TPCH's Q01: +1 Wicked cool! -- Crunchy Data - http://crunchydata.com PostgreSQL Support for Secure Enterprises Consulting, Training, & Open So

Re: Add CONTRIBUTING.md

On 05/29/2018 11:38 AM, Magnus Hagander wrote: > On Tue, May 29, 2018 at 5:36 PM, Andres Freund > wrote: > > Hi, > > A lot of people contribute in communities via github these days. We > should add a CONTRIBUTING.md that explains how to do so, given that we

Re: New committers announced at PGCon 2018

On 06/01/2018 05:14 PM, Andres Freund wrote: > On 2018-06-01 17:05:11 -0400, Tom Lane wrote: >> The core team is pleased to announce the appointment of seven >> new Postgres committers: >> >> Etsuro Fujita >> Peter Geoghegan >> Amit Kapila >> Alexander Korotkov >> Thomas Munro >> Michael Paquier >>

Re: commitfest 2018-07

On 06/05/2018 10:43 AM, Andres Freund wrote: > On 2018-06-05 10:20:55 -0400, Tom Lane wrote: >> Andres Freund writes: >>> I'd rather create a new 2018-07, and just manually move old patches to >>> it. Otherwise we'll not really focus on the glut of old things, but >>> everyone just restarts workin

Re: [Proposal] Table-level Transparent Data Encryption (TDE) and Key Management Service (KMS)

On 06/11/2018 05:22 AM, Masahiko Sawada wrote: > As per discussion at PGCon unconference, I think that firstly we need > to discuss what threats we want to defend database data against. Exactly. While certainly there is demand for encryption for the sake of "checking a box", different designs will

Re: missing toast table for pg_policy

On 06/15/2018 02:40 PM, John Naylor wrote: > On 2/19/18, Joe Conway wrote: >> The attached does exactly this. Gives all system tables toast tables >> except pg_class, pg_attribute, and pg_index, and includes cat version >> bump and regression test in misc_sanity. >>

Re: [Proposal] Table-level Transparent Data Encryption (TDE) and Key Management Service (KMS)

On 06/14/2018 12:19 PM, Masahiko Sawada wrote: > On Wed, Jun 13, 2018 at 10:20 PM, Joe Conway wrote: >> The idea has not been extensively fleshed out yet, but the thought was >> that we create column level POLICY, which would transparently apply some >> kind of transform o

Re: [Proposal] Table-level Transparent Data Encryption (TDE) and Key Management Service (KMS)

On 06/18/2018 09:49 AM, Robert Haas wrote: > On Wed, Jun 13, 2018 at 9:20 AM, Joe Conway wrote: >>> Also, if I understand correctly, at unconference session there also >>> were two suggestions about the design other than the suggestion by >>> Alexander: implemen

Re: [Proposal] Table-level Transparent Data Encryption (TDE) and Key Management Service (KMS)

On 06/18/2018 10:26 AM, Robert Haas wrote: > On Mon, Jun 18, 2018 at 10:12 AM, Joe Conway wrote: >> Not necessarily. Our pages probably have enough predictable bytes to aid >> cryptanalysis, compared to user data in a column which might not be very >> predicable. > >

Re: [Proposal] Table-level Transparent Data Encryption (TDE) and Key Management Service (KMS)

On 06/18/2018 10:52 AM, Tom Lane wrote: > Robert Haas writes: >> On Mon, Jun 18, 2018 at 10:12 AM, Joe Conway wrote: >>> Not necessarily. Our pages probably have enough predictable bytes to aid >>> cryptanalysis, compared to user data in a column which might

Re: [Proposal] Table-level Transparent Data Encryption (TDE) and Key Management Service (KMS)

On 06/20/2018 05:09 PM, Bruce Momjian wrote: > On Mon, Jun 18, 2018 at 09:49:20AM -0400, Robert Haas wrote: >> know the ordering of the values under whatever ordering semantics >> apply to that index. It's unclear to me how useful such information > > I don't think an ordered index is possible, o

Re: [Proposal] Table-level Transparent Data Encryption (TDE) and Key Management Service (KMS)

On 06/20/2018 05:05 PM, Bruce Momjian wrote: > On Mon, Jun 18, 2018 at 08:29:32AM -0400, Joe Conway wrote: >>>> Or >>>> maybe key management is really tied into the separately discussed effort >>>> to create SQL VARIABLEs somehow. >>> >>> C

Re: [Proposal] Table-level Transparent Data Encryption (TDE) and Key Management Service (KMS)

On 06/20/2018 05:03 PM, Bruce Momjian wrote: > On Wed, Jun 13, 2018 at 09:20:58AM -0400, Joe Conway wrote: >> The idea has not been extensively fleshed out yet, but the thought was >> that we create column level POLICY, which would transparently apply some >> kind of tran

Re: [Proposal] Table-level Transparent Data Encryption (TDE) and Key Management Service (KMS)

On 06/20/2018 05:12 PM, Bruce Momjian wrote: > On Mon, Jun 18, 2018 at 11:06:20AM -0400, Joe Conway wrote: >>> At the same time, having to have a bunch of independently-decipherable >>> short field values is not real secure either, especially if they're known >>>

Re: missing toast table for pg_policy

On 07/09/2018 09:16 PM, Michael Paquier wrote: > On Mon, Jul 09, 2018 at 02:45:26PM +0200, Peter Eisentraut wrote: >> On 15.06.18 21:15, Joe Conway wrote: >>> Not surprising -- thanks for the update. >>> >>>> It occurred to be that we could go fu

Re: [Proposal] Table-level Transparent Data Encryption (TDE) and Key Management Service (KMS)

On 6/13/19 11:07 AM, Bruce Momjian wrote: > On Thu, Jun 13, 2019 at 04:26:47PM +0900, Masahiko Sawada wrote: >> Yeah, in principle since data key of 2 tier key architecture should >> not go outside database I think we should not tell data keys to >> utility commands. So the rearranging WAL format s

Re: [Proposal] Table-level Transparent Data Encryption (TDE) and Key Management Service (KMS)

On 6/14/19 6:09 PM, Bruce Momjian wrote: > On Fri, Jun 14, 2019 at 02:27:17PM -0400, Joe Conway wrote: >> On 6/13/19 11:07 AM, Bruce Momjian wrote: >> > In addition, while the 8k blocks would use a block cipher, the WAL would >> > likely use a stream cipher, and

Re: [Proposal] Table-level Transparent Data Encryption (TDE) and Key Management Service (KMS)

On 6/15/19 9:28 PM, Bruce Momjian wrote: > On Fri, Jun 14, 2019 at 02:27:17PM -0400, Joe Conway wrote: >> On 6/13/19 11:07 AM, Bruce Momjian wrote: >> > On Thu, Jun 13, 2019 at 04:26:47PM +0900, Masahiko Sawada wrote: >> >> Yeah, in principle since data key of

Re: [Proposal] Table-level Transparent Data Encryption (TDE) and Key Management Service (KMS)

On 6/16/19 9:45 AM, Bruce Momjian wrote: > On Sun, Jun 16, 2019 at 07:07:20AM -0400, Joe Conway wrote: >> In any case it doesn't address my first point, which is limiting the >> volume encrypted with the same key. Another valid reason is you might >> have data at vary

Re: [Proposal] Table-level Transparent Data Encryption (TDE) and Key Management Service (KMS)

On 6/16/19 9:46 AM, Bruce Momjian wrote: > On Sun, Jun 16, 2019 at 09:45:09AM -0400, Bruce Momjian wrote: >> On Sun, Jun 16, 2019 at 07:07:20AM -0400, Joe Conway wrote: >> > And although I'm not proposing this for the first implementation, yet >> > another reason

Re: [Proposal] Table-level Transparent Data Encryption (TDE) and Key Management Service (KMS)

On 6/17/19 8:12 AM, Stephen Frost wrote: >> But there's about 0% chance we'll get that in v1, of course, so we need >> s "minimum viable product" to build on anyway. > > There seems like a whole lot of space between something very elaborate > and only supporting one key. I think this is exactly t

Re: [Proposal] Table-level Transparent Data Encryption (TDE) and Key Management Service (KMS)

On 6/17/19 8:29 AM, Masahiko Sawada wrote: > From perspective of cryptographic, I think the fine grained TDE would > be better solution. Therefore if we eventually want the fine grained > TDE I wonder if it might be better to develop the table/tablespace TDE > first while keeping it simple as much

Re: [Proposal] Table-level Transparent Data Encryption (TDE) and Key Management Service (KMS)

On 6/20/19 8:34 AM, Masahiko Sawada wrote: > I think even if we provide the per table encryption we can have > encryption keys per tablepaces. That is, all tables on the same > tablespace encryption use the same encryption keys but user can > control encrypted objects per tables. > >> Will we add

Re: [Proposal] Table-level Transparent Data Encryption (TDE) and Key Management Service (KMS)

On 7/8/19 10:19 AM, Bruce Momjian wrote: > When people are asking for multiple keys (not just for key rotation), > they are asking to have multiple keys that can be supplied by users only > when they need to access the data. Yes, the keys are always in the > datbase, but the feature request is tha

Re: [Proposal] Table-level Transparent Data Encryption (TDE) and Key Management Service (KMS)

On 7/8/19 11:56 AM, Peter Eisentraut wrote: > On 2019-07-08 17:47, Stephen Frost wrote: >> Of course, we can discuss if what websites do with over-the-wire >> encryption is sensible to compare to what we want to do in PG for >> data-at-rest, but then we shouldn't be talking about what websites do,

Re: [Proposal] Table-level Transparent Data Encryption (TDE) and Key Management Service (KMS)

On 7/8/19 6:04 PM, Stephen Frost wrote: > * Bruce Momjian (br...@momjian.us) wrote: >> Uh, well, renaming the user was a big problem, but that is the only case >> I can think of. I don't see that as an issue for block or WAL sequence >> numbers. If we want to use a different nonce, we have to fin

Re: [Proposal] Table-level Transparent Data Encryption (TDE) and Key Management Service (KMS)

On 7/9/19 4:34 AM, Tomas Vondra wrote: > On Mon, Jul 08, 2019 at 06:45:50PM -0400, Bruce Momjian wrote: >>On Mon, Jul 8, 2019 at 06:23:13PM -0400, Bruce Momjian wrote: >>> Yes, 'postgres' can be used to create a nice md5 rainbow table that >>> works on many servers --- good point. Are rainbow tab

Re: [Proposal] Table-level Transparent Data Encryption (TDE) and Key Management Service (KMS)

On 7/9/19 4:23 AM, Tomas Vondra wrote: > On Mon, Jul 08, 2019 at 06:24:40PM -0400, Joe Conway wrote: >>On 7/8/19 6:04 PM, Stephen Frost wrote: >>> * Bruce Momjian (br...@momjian.us) wrote: >>>> Uh, well, renaming the user was a big problem, but that is the only case

Re: [Proposal] Table-level Transparent Data Encryption (TDE) and Key Management Service (KMS)

On 7/9/19 6:07 AM, Peter Eisentraut wrote: > On 2019-07-08 18:09, Joe Conway wrote: >> In my mind, and in practice to a >> large extent, a postgres tablespace == a unique mount point. > > But a critical difference is that in file systems, a separate mount > point has it

Re: [Proposal] Table-level Transparent Data Encryption (TDE) and Key Management Service (KMS)

On 7/9/19 8:39 AM, Ryan Lambert wrote: > Hi Thomas, > >> CBC mode does require >> random nonces, other modes may be fine with even sequences as long as >> the values are not reused.    > > I disagree that CBC mode requires random nonces, at least based on what > NIST has published.  They only req

Re: [Proposal] Table-level Transparent Data Encryption (TDE) and Key Management Service (KMS)

On 7/9/19 11:11 AM, Bruce Momjian wrote: > On Tue, Jul 9, 2019 at 09:16:17AM -0400, Joe Conway wrote: >> On 7/9/19 8:39 AM, Ryan Lambert wrote: >> > Hi Thomas, >> > >> >> CBC mode does require >> >> random nonces, other modes may be fine with

Re: [Proposal] Table-level Transparent Data Encryption (TDE) and Key Management Service (KMS)

On 7/9/19 3:50 PM, Bruce Momjian wrote: > On Tue, Jul 9, 2019 at 02:09:38PM -0400, Joe Conway wrote: >> On 7/9/19 11:11 AM, Bruce Momjian wrote: >> > Good point about nonce and IV. I wonder if running the nonce >> > through the cipher with the key makes it random

Re: [Proposal] Table-level Transparent Data Encryption (TDE) and Key Management Service (KMS)

On 7/9/19 4:12 PM, Tomas Vondra wrote: > On Tue, Jul 09, 2019 at 03:50:39PM -0400, Bruce Momjian wrote: >>On Tue, Jul 9, 2019 at 02:09:38PM -0400, Joe Conway wrote: >>> the input nonce used to generate the IV could be something like >>> pg_class.oid and blocknum conc

Re: [Proposal] Table-level Transparent Data Encryption (TDE) and Key Management Service (KMS)

On 7/9/19 5:42 PM, Tomas Vondra wrote: > There are two basic ways to construct nonces - CSPRNG and sequences, and > then a combination of both, i.e. one part is generated from a sequence > and one randomly. > > FWIW not sure using OIDs as nonces directly is a good idea, as those are > inherently l

Re: [Proposal] Table-level Transparent Data Encryption (TDE) and Key Management Service (KMS)

On 7/9/19 7:28 PM, Stephen Frost wrote: > Greetings, > > * Joe Conway (m...@joeconway.com) wrote: >> On 7/9/19 5:42 PM, Tomas Vondra wrote: >> > There are two basic ways to construct nonces - CSPRNG and sequences, and >> > then a combination of both, i.e. one

Re: [Proposal] Table-level Transparent Data Encryption (TDE) and Key Management Service (KMS)

On 7/9/19 10:06 PM, Stephen Frost wrote: > Greetings, > > * Ryan Lambert (r...@rustprooflabs.com) wrote: >> > What I think Tomas is getting at here is that we don't write a page only >> > once. >> >> > A nonce of tableoid+pagenum will only be unique the first time we write >> > out that page. Se

Re: [Proposal] Table-level Transparent Data Encryption (TDE) and Key Management Service (KMS)

On 7/10/19 2:40 AM, Masahiko Sawada wrote: > On Tue, Jul 9, 2019 at 10:16 PM Joe Conway wrote: >> >> On 7/9/19 8:39 AM, Ryan Lambert wrote: >> > Hi Thomas, >> > >> >> CBC mode does require >> >> random nonces, other modes may be fine with

Re: [Proposal] Table-level Transparent Data Encryption (TDE) and Key Management Service (KMS)

On 7/10/19 2:38 AM, Masahiko Sawada wrote: > On Tue, Jul 9, 2019 at 9:01 PM Joe Conway wrote: >> >> On 7/9/19 6:07 AM, Peter Eisentraut wrote: >> > On 2019-07-08 18:09, Joe Conway wrote: >> >> In my mind, and in practice to a >> >> large exten

Re: [Proposal] Table-level Transparent Data Encryption (TDE) and Key Management Service (KMS)

On 7/10/19 4:47 AM, Antonin Houska wrote: > Tomas Vondra wrote: >> I don't think that works, because that'd mean we're encrypting the same >> page with the same nonce over and over, which means reusing the reuse >> (even if you hash/encrypt it). Or did I miss something? > > I found out that it's

Re: [Proposal] Table-level Transparent Data Encryption (TDE) and Key Management Service (KMS)

On 7/10/19 4:24 AM, Antonin Houska wrote: > Joe Conway wrote: > >> On 7/8/19 6:04 PM, Stephen Frost wrote: >> > * Bruce Momjian (br...@momjian.us) wrote: >> >> Uh, well, renaming the user was a big problem, but that is the only case >> >> I can thin

Re: [Proposal] Table-level Transparent Data Encryption (TDE) and Key Management Service (KMS)

On 7/10/19 2:45 AM, Masahiko Sawada wrote: > On Wed, Jul 10, 2019 at 11:06 AM Stephen Frost wrote: >> >> Greetings, >> >> * Ryan Lambert (r...@rustprooflabs.com) wrote: >> > > What I think Tomas is getting at here is that we don't write a page only >> > > once. >> > >> > > A nonce of tableoid+page

Re: [Proposal] Table-level Transparent Data Encryption (TDE) and Key Management Service (KMS)

On 7/10/19 8:34 AM, Stephen Frost wrote: > Greetings, > > * Joe Conway (m...@joeconway.com) wrote: >> On 7/9/19 7:28 PM, Stephen Frost wrote: >> > * Joe Conway (m...@joeconway.com) wrote: >> >> On 7/9/19 5:42 PM, Tomas Vondra wrote: >> >> > Th

Re: [Proposal] Table-level Transparent Data Encryption (TDE) and Key Management Service (KMS)

On 7/10/19 3:53 PM, Alvaro Herrera wrote: > On 2019-Jul-10, Bruce Momjian wrote: > >> Good, so I think we all now agree we have to put the nonce >> (pg_class.oid, LSN, page-number) though the cipher using the secret. (been traveling -- just trying to get caught up on this thread) > Actually, why

Re: [Proposal] Table-level Transparent Data Encryption (TDE) and Key Management Service (KMS)

On 7/11/19 6:37 PM, Bruce Momjian wrote: > On Wed, Jul 10, 2019 at 12:26:24PM -0400, Bruce Momjian wrote: >> On Wed, Jul 10, 2019 at 08:31:17AM -0400, Joe Conway wrote: >>> Please see my other reply (and >>> https://nvlpubs.nist.gov/nistpubs/Legacy/SP/nistspecialpublicat

Re: [Proposal] Table-level Transparent Data Encryption (TDE) and Key Management Service (KMS)

On 7/12/19 2:45 PM, Bruce Momjian wrote: > On Fri, Jul 12, 2019 at 12:41:19PM -0600, Ryan Lambert wrote: >> >> I vote for AES 256 rather than 128. >> > >> > Why?  This page seems to think 128 is sufficient: >> > >> >         https://crypto.stackexchange.com/questions/20/ >> what-are-the-practical-d

Re: [Proposal] Table-level Transparent Data Encryption (TDE) and Key Management Service (KMS)

On 7/11/19 9:05 PM, Bruce Momjian wrote: > On Thu, Jul 11, 2019 at 08:41:52PM -0400, Joe Conway wrote: >> On 7/11/19 6:37 PM, Bruce Momjian wrote: >> > Our first implementation will encrypt the entire cluster. We can later >> > consider encryption per table or ta

Re: [Proposal] Table-level Transparent Data Encryption (TDE) and Key Management Service (KMS)

On 7/13/19 9:38 AM, Joe Conway wrote: > On 7/11/19 9:05 PM, Bruce Momjian wrote: >> On Thu, Jul 11, 2019 at 08:41:52PM -0400, Joe Conway wrote: >>> On 7/11/19 6:37 PM, Bruce Momjian wrote: >>> > Our first implementation will encrypt the entire cluster. We can later

Re: [Proposal] Table-level Transparent Data Encryption (TDE) and Key Management Service (KMS)

On 7/13/19 2:41 PM, Joe Conway wrote: > [2] > https://www.postgresql.org/message-id/20190708194733.cztnwhqge4acepzw%40development BTW I managed to mess up this link. This is what I intended to link there (from Tomas): [2] https://www.kernel.org/doc/html/latest/filesystems/fscrypt.html I a

Re: [Proposal] Table-level Transparent Data Encryption (TDE) and Key Management Service (KMS)

On 7/13/19 5:58 PM, Tomas Vondra wrote: > On Sat, Jul 13, 2019 at 02:41:34PM -0400, Joe Conway wrote: >>[2] also says provides additional support for AES 256. It also mentions >>CBC versus XTS -- I came across this elsewhere and it bears discussion: >> >>"C

Re: sepgsql seems rather thoroughly broken on Fedora 30

On 7/17/19 12:54 PM, Tom Lane wrote: > I wrote: >> I tried to run the contrib/sepgsql tests, following the instructions, >> on a recently-set-up Fedora 30 machine. I've done that successfully >> on previous Fedora releases, but it's no go with F30. >> ... >> I'm pretty sure the test recipe last wo

Re: pg_config wrongly marked as not parallel safe?

On 11/26/18 6:45 PM, Andres Freund wrote: > Hi, > > Triggered by the thread at [1] I looked for functions marked as > immutable but not parallel safe. > > postgres[19492][1]=# SELECT oid::regprocedure, provolatile, proparallel FROM > pg_proc WHERE provolatile = 'i' AND proparallel != 's'; > ┌───

Re: pg_config wrongly marked as not parallel safe?

On 11/26/18 7:08 PM, Andres Freund wrote: > On 2018-11-26 19:04:46 -0500, Joe Conway wrote: >> Not intentional. Though, sitting here chatting with Stephen about it, I >> am now wondering if pg_config() should actually be marked immutable: >> >> select * from pg_con

Re: pg_config wrongly marked as not parallel safe?

On 11/30/18 3:30 AM, Kyotaro HORIGUCHI wrote: > # And returning to the topic, I vote for pg_config should be "stable". And on that note, Does this change does warrant backpatching, or should be applied to master only? Joe -- Crunchy Data - http://crunchydata.com PostgreSQL Support for Secure En

Re: [Proposal] Table-level Transparent Data Encryption (TDE) and Key Management Service (KMS)

On 7/27/19 3:02 PM, Sehrope Sarkuni wrote: > More generally, without a cryptographic MAC I don't think it's > possible to provide any meaningful malicious tamper detection. And > even that would have to be off-page to deal with page replay (which I > think is out of scope). > > [1]: https://en.wik

Re: [Proposal] Table-level Transparent Data Encryption (TDE) and Key Management Service (KMS)

On 7/29/19 6:11 PM, Sehrope Sarkuni wrote: > On Mon, Jul 29, 2019 at 4:15 PM Alvaro Herrera > wrote: > > On 2019-Jul-27, Sehrope Sarkuni wrote: > > > Given the non-cryptographic nature of CRC and its 16-bit size, I'd > > round down the malicious tampe

Re: [Proposal] Table-level Transparent Data Encryption (TDE) and Key Management Service (KMS)

On 8/19/19 8:51 AM, Ahsan Hadi wrote: > I have shared a calendar invite for TDE/KMS weekly meeting with the > members who expressed interest of joining the meeting in this chain. > Hopefully I haven't missed anyone. > > I am not aware of everyone's timezone but I have tried to setup a time > that'

Re: [Proposal] Table-level Transparent Data Encryption (TDE) and Key Management Service (KMS)

On 8/26/19 2:53 AM, Masahiko Sawada wrote: > I guess that this depends on the number of encryption keys we use. If > we have encryption keys per tablespace or database the number of keys > would be at most several dozen or several hundred. It's enough to have > them in flat-file format on the disk

RFC: seccomp-bpf support

SECCOMP ("SECure COMPuting with filters") is a Linux kernel syscall filtering mechanism which allows reduction of the kernel attack surface by preventing (or at least audit logging) normally unused syscalls. Quoting from this link: https://www.kernel.org/doc/Documentation/prctl/seccomp_filter.txt

Re: RFC: seccomp-bpf support

On 8/28/19 1:03 PM, Peter Eisentraut wrote: > On 2019-08-28 17:13, Joe Conway wrote: >> * systemd does not implement seccomp filters by default. Packagers may >> decide to do so, but there is no guarantee. Adding them post install >> potentially requires cooperation by g

Re: RFC: seccomp-bpf support

On 8/28/19 12:47 PM, David Fetter wrote: > On Wed, Aug 28, 2019 at 11:13:27AM -0400, Joe Conway wrote: >> SECCOMP ("SECure COMPuting with filters") is a Linux kernel syscall >> filtering mechanism which allows reduction of the kernel attack surface >> by preven

Re: RFC: seccomp-bpf support

On 8/28/19 4:07 PM, Peter Eisentraut wrote: > On 2019-08-28 21:38, Joshua Brindle wrote: >> I think we need to reign in the thread somewhat. The feature allows >> end users to define some sandboxing within PG. Nothing is being forced >> on anyone > > Features come with a maintenance cost. If we s

Re: RFC: seccomp-bpf support

On 8/29/19 10:00 AM, Tom Lane wrote: > Joe Conway writes: >> Clearly Joshua and I disagree, but understand that the consensus is not >> on our side. It is our assessment that PostgreSQL will be subject to >> seccomp willingly or not (e.g., via docker, systemd, etc.) and the

Re: add a MAC check for TRUNCATE

On 9/6/19 11:26 AM, Yuli Khodorkovskiy wrote: > On Fri, Sep 6, 2019 at 10:40 AM Stephen Frost wrote: >> There are actual reasons why the 'DELETE' privilege is *not* the same as >> 'TRUNCATE' in PostgreSQL and I'm really not convinced that we should >> just be tossing that distinction out the windo

Re: add a MAC check for TRUNCATE

On 9/6/19 2:18 PM, Tom Lane wrote: > Yuli Khodorkovskiy writes: >> On Fri, Sep 6, 2019 at 11:57 AM Tom Lane wrote: >>> Well, the larger question, independent of the regression tests, is >>> will the new policy work at all on older SELinux? If not, that >>> doesn't seem very acceptable. > >> The

Re: add a MAC check for TRUNCATE

On 9/6/19 2:13 PM, Yuli Khodorkovskiy wrote: > As Joe Conway pointed out to me out of band, the build animal for RHEL > 7 has handle_unknown set to `0`. Are there any other concerns with > this approach? You mean deny_unknown I believe. "Allow unknown object class / permissions.

Re: add a MAC check for TRUNCATE

On 9/6/19 8:07 PM, Tom Lane wrote: > Joe Conway writes: >> On 9/6/19 2:18 PM, Tom Lane wrote: >>> sepgsql hasn't worked on RHEL6 in a long time, if ever; it requires >>> a newer version of libselinux than what ships in RHEL6. So I'm not >>> concerne

Re: doc - add missing documentation for "acldefault"

On 08/03/2018 09:04 AM, Fabien COELHO wrote: > Here is a version of the patch which documents briefly all aclitem-related > functions, in a separate table. I claimed this patch for review and commit. Comments: --- * There is a comment in src/backend/utils/adt/acl.c noting that acldefault is "no

Re: doc - add missing documentation for "acldefault"

On 09/19/2018 10:54 AM, Tom Lane wrote: > Joe Conway writes: >> * I do believe aclitemeq() has utility outside internal purposes. > > Our normal policy is that we do not document functions that are meant to > be invoked through operators. The \df output saying that is suffic

Re: doc - add missing documentation for "acldefault"

On 09/19/2018 12:30 PM, John Naylor wrote: > On 9/19/18, Tom Lane wrote: >> However, I don't object to documenting any function that has its >> own pg_description string. > > Speaking of, that description string seems to have been neglected. > I've attached a remedy for that. Thanks, will take c

Re: doc - add missing documentation for "acldefault"

On 09/19/2018 11:18 AM, Joe Conway wrote: > On 09/19/2018 10:54 AM, Tom Lane wrote: >> Joe Conway writes: >>> * I do believe aclitemeq() has utility outside internal purposes. >> >> Our normal policy is that we do not document functions that are meant to >> be

Re: doc - add missing documentation for "acldefault"

On 09/21/2018 01:51 PM, Joe Conway wrote: > On 09/19/2018 11:18 AM, Joe Conway wrote: >> On 09/19/2018 10:54 AM, Tom Lane wrote: >>> So maybe what we really need is a table of operators not functions. >> >> Good idea -- I will take a look at that. >> >&g

Re: doc - add missing documentation for "acldefault"

On 09/24/2018 10:01 AM, Tom Lane wrote: > Joe Conway writes: >> Having seen none, committed/pushed. This did not seem worth >> back-patching, so I only pushed to master. > > I don't see anything on gitmaster? Hmm, yes, interesting -- I must of messed up my local git re

Re: doc - add missing documentation for "acldefault"

On 09/24/2018 10:09 AM, Joe Conway wrote: > On 09/24/2018 10:01 AM, Tom Lane wrote: >> Joe Conway writes: >>> Having seen none, committed/pushed. This did not seem worth >>> back-patching, so I only pushed to master. >> >> I don't see anything on git

Re: has_column_privilege behavior (was Re: Assert failed in snprintf.c)

On 10/01/2018 02:41 PM, Stephen Frost wrote: > Tom Lane (t...@sss.pgh.pa.us) wrote: >> But it's not quite clear to me what we want the behavior for bad column >> name to be. A case could be made for either of: >> >> * If either the table OID is bad, or the OID is OK but there's no such >> column,

Re: Commit fest 2018-09

On 10/02/2018 10:13 AM, Tom Lane wrote: > Michael Paquier writes: >> Thanks to all who participated in the patch review, authoring, and >> everybody else who helped in making the different patches move forward. > > Thanks for being CFM! I know it's a lot of work ... +10! Joe -- Crunchy Data

Re: [HACKERS] Row Level Security Bug ?

On 11/13/2017 09:09 PM, Andrea Adami wrote: > As suggested from Joe i changed the db definition as enclosed. > Now when i do: > > select * fom schools  > > all works fine  > > but when i do: [SELECT from VIEW] > always i get the error:  > > permission denied for relation schools > SQL state:

<    1   2   3   4   5   6   >