On Mon, Aug 31, 2015 at 05:46:08PM -0400, Bruce Momjian wrote:
> On Tue, Jul 28, 2015 at 04:23:36PM -0300, Alvaro Herrera wrote:
> > Josh Berkus wrote:
> > > On 07/28/2015 11:58 AM, Robert Haas wrote:
> > > > I'd be strongly in favour of teaching GRANT, SECURITY LABEL, COMMENT
> > > >> ON DATABASE,
On Tue, Jul 28, 2015 at 04:23:36PM -0300, Alvaro Herrera wrote:
> Josh Berkus wrote:
> > On 07/28/2015 11:58 AM, Robert Haas wrote:
> > > I'd be strongly in favour of teaching GRANT, SECURITY LABEL, COMMENT
> > >> ON DATABASE, etc to recognise CURRENT_DATABASE as a keyword. Then
> > >> dumping them
On Thu, Jul 30, 2015 at 10:37:33PM -0400, Adam Brightwell wrote:
> On Thu, Jul 30, 2015 at 02:26:34PM -0400, Robert Haas wrote:
> >> 1. "pg_dumpall -g"
> >> 2. "pg_dump --create" per database
> >
> > Gah, OK, I see your point. But we better document this, because if
> > you need a PhD in PostgreSQ
>> 1. "pg_dumpall -g"
>> 2. "pg_dump --create" per database
>
> Gah, OK, I see your point. But we better document this, because if
> you need a PhD in PostgreSQL-ology to take a backup, we're not in a
> good place.
Agreed. Though, honestly, I find this to be a cumbersome approach. I
think it ju
On Thu, Jul 30, 2015 at 2:49 AM, Noah Misch wrote:
> What exact formula did you have in mind? It must not be merely
>
> 1. "pg_dumpall -g"
> 2. "pg_dump" (without --create) per database
>
> which _never_ works: it emits no CREATE DATABASE statements. Perhaps this?
>
> 1. "pg_dumpall -g"
> 2. Iss
Noah Misch wrote:
> What exact formula did you have in mind? It must not be merely
>
> 1. "pg_dumpall -g"
> 2. "pg_dump" (without --create) per database
>
> which _never_ works: it emits no CREATE DATABASE statements. Perhaps this?
>
> 1. "pg_dumpall -g"
> 2. Issue a handwritten CREATE DATABA
On Wed, Jul 29, 2015 at 10:50:53AM -0400, Robert Haas wrote:
> On Wed, Jul 29, 2015 at 12:39 AM, Noah Misch wrote:
> > On Tue, Jul 28, 2015 at 03:36:13PM -0400, Robert Haas wrote:
> >> On Tue, Jul 28, 2015 at 3:33 PM, Andres Freund wrote:
> >> > Hm? Let me try again: If the admin does a ALTER DA
On Wed, Jul 29, 2015 at 12:39 AM, Noah Misch wrote:
> On Tue, Jul 28, 2015 at 03:36:13PM -0400, Robert Haas wrote:
>> On Tue, Jul 28, 2015 at 3:33 PM, Andres Freund wrote:
>> > Hm? Let me try again: If the admin does a ALTER DATABASE ... SET guc =
>> > ... *before* restoring a backup and the bac
On Tue, Jul 28, 2015 at 03:36:13PM -0400, Robert Haas wrote:
> On Tue, Jul 28, 2015 at 3:33 PM, Andres Freund wrote:
> > Hm? Let me try again: If the admin does a ALTER DATABASE ... SET guc =
> > ... *before* restoring a backup and the backup does contain a setting
> > for the same guc, but with
On Tue, Jul 28, 2015 at 3:33 PM, Andres Freund wrote:
> On 2015-07-28 15:27:51 -0400, Robert Haas wrote:
>> On Tue, Jul 28, 2015 at 3:16 PM, Andres Freund wrote:
>> > On 2015-07-28 15:14:11 -0400, Robert Haas wrote:
>> >> On Tue, Jul 28, 2015 at 3:10 PM, Andres Freund wrote:
>> >> > DBA creates
On 2015-07-28 15:27:51 -0400, Robert Haas wrote:
> On Tue, Jul 28, 2015 at 3:16 PM, Andres Freund wrote:
> > On 2015-07-28 15:14:11 -0400, Robert Haas wrote:
> >> On Tue, Jul 28, 2015 at 3:10 PM, Andres Freund wrote:
> >> > DBA creates a database and sets some properties (security labels, gucs,
>
On Tue, Jul 28, 2015 at 3:16 PM, Andres Freund wrote:
> On 2015-07-28 15:14:11 -0400, Robert Haas wrote:
>> On Tue, Jul 28, 2015 at 3:10 PM, Andres Freund wrote:
>> > DBA creates a database and sets some properties (security labels, gucs,
>> > acls) on it. Then goes on to restore a backup. Unfort
Josh Berkus wrote:
> On 07/28/2015 11:58 AM, Robert Haas wrote:
> > I'd be strongly in favour of teaching GRANT, SECURITY LABEL, COMMENT
> >> ON DATABASE, etc to recognise CURRENT_DATABASE as a keyword. Then
> >> dumping them in pg_dump --create, and in pg_dump -Fc .
> >>
> >> In practice I see zer
* Andres Freund (and...@anarazel.de) wrote:
> On 2015-07-28 15:14:11 -0400, Robert Haas wrote:
> > On Tue, Jul 28, 2015 at 3:10 PM, Andres Freund wrote:
> > > DBA creates a database and sets some properties (security labels, gucs,
> > > acls) on it. Then goes on to restore a backup. Unfortunately
On 07/28/2015 11:58 AM, Robert Haas wrote:
> I'd be strongly in favour of teaching GRANT, SECURITY LABEL, COMMENT
>> ON DATABASE, etc to recognise CURRENT_DATABASE as a keyword. Then
>> dumping them in pg_dump --create, and in pg_dump -Fc .
>>
>> In practice I see zero real use of pg_dumpall withou
On 2015-07-28 15:14:11 -0400, Robert Haas wrote:
> On Tue, Jul 28, 2015 at 3:10 PM, Andres Freund wrote:
> > DBA creates a database and sets some properties (security labels, gucs,
> > acls) on it. Then goes on to restore a backup. Unfortunately that backup
> > might, or might not, overwrite the p
On Tue, Jul 28, 2015 at 3:10 PM, Andres Freund wrote:
> On 2015-07-28 15:05:01 -0400, Robert Haas wrote:
>> On Tue, Jul 28, 2015 at 3:03 PM, Andres Freund wrote:
>> > On 2015-07-28 14:58:26 -0400, Robert Haas wrote:
>> >> Yes, I think we should make restoring the database's properties the
>> >> j
On 2015-07-28 15:05:01 -0400, Robert Haas wrote:
> On Tue, Jul 28, 2015 at 3:03 PM, Andres Freund wrote:
> > On 2015-07-28 14:58:26 -0400, Robert Haas wrote:
> >> Yes, I think we should make restoring the database's properties the
> >> job of pg_dump and remove it completely from pg_dumpall, unles
On Tue, Jul 28, 2015 at 3:03 PM, Andres Freund wrote:
> On 2015-07-28 14:58:26 -0400, Robert Haas wrote:
>> Yes, I think we should make restoring the database's properties the
>> job of pg_dump and remove it completely from pg_dumpall, unless we can
>> find a case where that's really going to brea
On 2015-07-28 14:58:26 -0400, Robert Haas wrote:
> Yes, I think we should make restoring the database's properties the
> job of pg_dump and remove it completely from pg_dumpall, unless we can
> find a case where that's really going to break things.
CREATE DATABASE blarg;
SECURITY LABEL ON blarg IS
* Robert Haas (robertmh...@gmail.com) wrote:
> On Sun, Jul 26, 2015 at 11:43 PM, Craig Ringer wrote:
> > On 20 July 2015 at 01:18, Noah Misch wrote:
> >> On Wed, Jul 15, 2015 at 11:08:53AM +0200, Andres Freund wrote:
> >>> On 2015-07-15 12:04:40 +0300, Alvaro Herrera wrote:
> >>> > Andres Freund
On Sun, Jul 26, 2015 at 11:43 PM, Craig Ringer wrote:
> On 20 July 2015 at 01:18, Noah Misch wrote:
>> On Wed, Jul 15, 2015 at 11:08:53AM +0200, Andres Freund wrote:
>>> On 2015-07-15 12:04:40 +0300, Alvaro Herrera wrote:
>>> > Andres Freund wrote:
>>> > > One thing worth mentioning is that argua
On 20 July 2015 at 01:18, Noah Misch wrote:
> On Wed, Jul 15, 2015 at 11:08:53AM +0200, Andres Freund wrote:
>> On 2015-07-15 12:04:40 +0300, Alvaro Herrera wrote:
>> > Andres Freund wrote:
>> > > One thing worth mentioning is that arguably the problem is caused by the
>> > > fact that we're here
On Thu, Jul 23, 2015 at 12:14:14PM -0400, Robert Haas wrote:
> On Wed, Jul 22, 2015 at 3:42 PM, Adam Brightwell
> wrote:
> >> I like Noah's proposal of having pg_dump --create reproduce all
> >> database-level state.
> >
> > Should it be enabled by default? If so, then wouldn't it make more
> >
On Wed, Jul 22, 2015 at 3:42 PM, Adam Brightwell
wrote:
>> I don't think there's any line near pg_dumpall. That tool seems to
>> have grown out of desperation without much actual design. I think it
>> makes more sense to plan around that's the best pg_dump behavior for the
>> various use cases.
> While I'd favor optional --no-create if we were designing fresh, it's not
> worth breaking user scripts by changing that now.
Agreed. So, --create would not be enabled by default.
>> How would this handle related global objects? It seems like this part
>> could get a little tricky.
>
> Like ro
On Wed, Jul 22, 2015 at 03:42:58PM -0400, Adam Brightwell wrote:
> > I like Noah's proposal of having pg_dump --create reproduce all
> > database-level state.
>
> Should it be enabled by default? If so, then wouldn't it make more
> sense to call it --no-create and do the opposite? So, --no-creat
On Wed, Jul 22, 2015 at 4:42 PM, Adam Brightwell <
adam.brightw...@crunchydatasolutions.com> wrote:
>
> [...]
>
> Also, I think this would potentially conflict with what FabrÃzio is
> doing with CURRENT_DATABASE on COMMENT, though, I think it might be a
> preferable solution.
>
> https://commitfest
> I don't think there's any line near pg_dumpall. That tool seems to
> have grown out of desperation without much actual design. I think it
> makes more sense to plan around that's the best pg_dump behavior for the
> various use cases.
Ok.
> I like Noah's proposal of having pg_dump --create rep
Noah Misch wrote:
> On Mon, Jul 20, 2015 at 07:01:14PM -0400, Adam Brightwell wrote:
> > I think that makes sense, but what about other DATABASE level info
> > such as COMMENT? Should that also be ignored by pg_dump as well? I'm
> > specifically thinking of the discussion from the following thre
On Mon, Jul 20, 2015 at 07:01:14PM -0400, Adam Brightwell wrote:
> > Consistency with existing practice would indeed have pg_dump ignore
> > pg_shseclabel and have pg_dumpall reproduce its entries.
>
> I think that makes sense, but what about other DATABASE level info
> such as COMMENT? Should th
> Consistency with existing practice would indeed have pg_dump ignore
> pg_shseclabel and have pg_dumpall reproduce its entries.
I think that makes sense, but what about other DATABASE level info
such as COMMENT? Should that also be ignored by pg_dump as well? I'm
specifically thinking of the di
On Wed, Jul 15, 2015 at 11:08:53AM +0200, Andres Freund wrote:
> On 2015-07-15 12:04:40 +0300, Alvaro Herrera wrote:
> > Andres Freund wrote:
> > > One thing worth mentioning is that arguably the problem is caused by the
> > > fact that we're here emitting database level information in pg_dump,
> >
On 2015-07-15 12:04:40 +0300, Alvaro Herrera wrote:
> Andres Freund wrote:
> > One thing worth mentioning is that arguably the problem is caused by the
> > fact that we're here emitting database level information in pg_dump,
> > normally only done for dumpall.
>
> ... the reason for which is proba
Andres Freund wrote:
> One thing worth mentioning is that arguably the problem is caused by the
> fact that we're here emitting database level information in pg_dump,
> normally only done for dumpall.
... the reason for which is probably the lack of CURRENT_DATABASE as a
database specifier. It m
On 2015-07-14 13:09:26 -0400, Adam Brightwell wrote:
> All,
>
> >> I won't have time to do anything about this anytime soon, but I think we
> >> should fix that at some point. Shall I put this on the todo? Or do we
> >> want to create an 'open items' page that's not major version specific?
> >
>
> That doesn't answer my question. I'm talking about a client and server
> running on the same system with SELinux MLS policy so that getpeercon
> will return the context of the client process unless it has explicitly
> sets the socket create context . So again will postgresql if the
> sepgsql modu
>> Cc: Robert Haas; Adam Brightwell; Andres Freund;
>> pgsql-hackers@postgresql.org;
>> Alvaro Herrera
>> Subject: Re: [HACKERS] security labels on databases are bad for dump &
>> restore
>>
>> So if I label a table with an SELinux context and the
ct: Re: [HACKERS] security labels on databases are bad for dump & restore
>
> So if I label a table with an SELinux context and the type of my
> client connection does not have policy to be able to access the table
> type will an AVC be generated and the access denied?
>
> Ted
So if I label a table with an SELinux context and the type of my
client connection does not have policy to be able to access the table
type will an AVC be generated and the access denied?
Ted
On Tue, Jul 14, 2015 at 12:53 PM, Kohei KaiGai wrote:
> 2015-07-15 2:39 GMT+09:00 Ted Toth :
>> That's e
2015-07-15 2:39 GMT+09:00 Ted Toth :
> That's exactly what I'm talking about like I said KaiGais branch was
> never merged into the mainline so I do not believe that it is used at
> all.
>
It depends on the definition of "integrated".
The PostgreSQL core offers an infrastructure for label based sec
That's exactly what I'm talking about like I said KaiGais branch was
never merged into the mainline so I do not believe that it is used at
all.
Ted
On Tue, Jul 14, 2015 at 12:28 PM, Robert Haas wrote:
> On Tue, Jul 14, 2015 at 1:22 PM, Ted Toth wrote:
>> I'm sort of new to this so maybe I'm mis
On Tue, Jul 14, 2015 at 1:22 PM, Ted Toth wrote:
> I'm sort of new to this so maybe I'm missing something but since the
> sepgsql SELinux userspace object manager was never integrated into
> postgresql (AFAIK KaiGais branch was never merged into the mainline)
> who uses these labels? What use are
I'm sort of new to this so maybe I'm missing something but since the
sepgsql SELinux userspace object manager was never integrated into
postgresql (AFAIK KaiGais branch was never merged into the mainline)
who uses these labels? What use are they?
Ted
On Tue, Jul 14, 2015 at 12:09 PM, Adam Brightw
All,
>> I won't have time to do anything about this anytime soon, but I think we
>> should fix that at some point. Shall I put this on the todo? Or do we
>> want to create an 'open items' page that's not major version specific?
>
> I think adding it to the TODO would be great.
I'd be willing to
On Fri, Jul 10, 2015 at 7:57 AM, Andres Freund wrote:
> pg_dump dumps security labels on databases. Which makes sense. The
> problem is that they're dumped including the database name.
>
> Which means that if you dump a database and restore it into a
> differently named one you'll either get a fai
Hi,
pg_dump dumps security labels on databases. Which makes sense. The
problem is that they're dumped including the database name.
Which means that if you dump a database and restore it into a
differently named one you'll either get a failure because the database
does not exist, or worse you'll u
47 matches
Mail list logo
