Thread: Proposing COPY .. WITH PERMISSIVE

Proposing COPY .. WITH PERMISSIVE

From
dinesh kumar
Date:
Hi All,

Would like to propose PERMISSIVE mode for the COPY created out files.
I mean, at this moment, if do "COPY" as postgres instance owner, i can able
to read the file as non instance user as well, and would like to restrict this to
instance owner WITH PERMISSIVE option.

Let me know your thoughts on this.

Regards,
Dinesh

Re: Proposing COPY .. WITH PERMISSIVE

From
Robert Haas
Date:
On Wed, Jul 22, 2015 at 11:29 PM, dinesh kumar <dineshkumar02@gmail.com> wrote:
> Would like to propose PERMISSIVE mode for the COPY created out files.
> I mean, at this moment, if do "COPY" as postgres instance owner, i can able
> to read the file as non instance user as well, and would like to restrict
> this to
> instance owner WITH PERMISSIVE option.
>
> Let me know your thoughts on this.

I don't understand the proposal.

-- 
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company



Re: Proposing COPY .. WITH PERMISSIVE

From
Andres Freund
Date:
On 2015-07-23 11:26:27 -0400, Robert Haas wrote:
> On Wed, Jul 22, 2015 at 11:29 PM, dinesh kumar <dineshkumar02@gmail.com> wrote:
> > Would like to propose PERMISSIVE mode for the COPY created out files.
> > I mean, at this moment, if do "COPY" as postgres instance owner, i can able
> > to read the file as non instance user as well, and would like to restrict
> > this to
> > instance owner WITH PERMISSIVE option.
> >
> > Let me know your thoughts on this.
> 
> I don't understand the proposal.

I understand it as PERMISSIVE := chmod 777 the target file of a COPY TO.



Re: Proposing COPY .. WITH PERMISSIVE

From
Robert Haas
Date:
On Thu, Jul 23, 2015 at 11:32 AM, Andres Freund <andres@anarazel.de> wrote:
> On 2015-07-23 11:26:27 -0400, Robert Haas wrote:
>> On Wed, Jul 22, 2015 at 11:29 PM, dinesh kumar <dineshkumar02@gmail.com> wrote:
>> > Would like to propose PERMISSIVE mode for the COPY created out files.
>> > I mean, at this moment, if do "COPY" as postgres instance owner, i can able
>> > to read the file as non instance user as well, and would like to restrict
>> > this to
>> > instance owner WITH PERMISSIVE option.
>> >
>> > Let me know your thoughts on this.
>>
>> I don't understand the proposal.
>
> I understand it as PERMISSIVE := chmod 777 the target file of a COPY TO.

That doesn't sound like an especially good idea.  What if I want mode 770?

-- 
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company



Re: Proposing COPY .. WITH PERMISSIVE

From
dinesh kumar
Date:
Hi Robert/Andres,

On Thu, Jul 23, 2015 at 8:34 AM, Robert Haas <robertmhaas@gmail.com> wrote:
On Thu, Jul 23, 2015 at 11:32 AM, Andres Freund <andres@anarazel.de> wrote:
> On 2015-07-23 11:26:27 -0400, Robert Haas wrote:
>> On Wed, Jul 22, 2015 at 11:29 PM, dinesh kumar <dineshkumar02@gmail.com> wrote:
>> > Would like to propose PERMISSIVE mode for the COPY created out files.
>> > I mean, at this moment, if do "COPY" as postgres instance owner, i can able
>> > to read the file as non instance user as well, and would like to restrict
>> > this to
>> > instance owner WITH PERMISSIVE option.
>> >
>> > Let me know your thoughts on this.
>>
>> I don't understand the proposal.
>
> I understand it as PERMISSIVE := chmod 777 the target file of a COPY TO.

That doesn't sound like an especially good idea.  What if I want mode 770?


Sorry for my  unclear description about the proposal.

"WITH PERMISSIVE" is equal to our existing behavior. That is, chmod=644 on the created files.

If User don't specify "PERMISSIVE" as an option, then the chmod=600 on created files. In this way, we can restrict the other users from reading these files.

Let me know if i am still bad at explaining things here.

Thanks in advance.

Regards,
Dinesh

--
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company

Re: Proposing COPY .. WITH PERMISSIVE

From
Robert Haas
Date:
On Thu, Jul 23, 2015 at 12:19 PM, dinesh kumar <dineshkumar02@gmail.com> wrote:
> Sorry for my  unclear description about the proposal.
>
> "WITH PERMISSIVE" is equal to our existing behavior. That is, chmod=644 on
> the created files.
>
> If User don't specify "PERMISSIVE" as an option, then the chmod=600 on
> created files. In this way, we can restrict the other users from reading
> these files.

There might be some benefit in allowing the user to choose the
permissions, but (1) I doubt we want to change the default behavior
and (2) providing only two options doesn't seem flexible enough.

-- 
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company



Re: Proposing COPY .. WITH PERMISSIVE

From
dinesh kumar
Date:
On Thu, Jul 23, 2015 at 9:21 AM, Robert Haas <robertmhaas@gmail.com> wrote:
On Thu, Jul 23, 2015 at 12:19 PM, dinesh kumar <dineshkumar02@gmail.com> wrote:
> Sorry for my  unclear description about the proposal.
>
> "WITH PERMISSIVE" is equal to our existing behavior. That is, chmod=644 on
> the created files.
>
> If User don't specify "PERMISSIVE" as an option, then the chmod=600 on
> created files. In this way, we can restrict the other users from reading
> these files.

There might be some benefit in allowing the user to choose the
permissions, but (1) I doubt we want to change the default behavior
and (2) providing only two options doesn't seem flexible enough.


Thanks for your inputs Robert.

1) IMO, we will keep the exiting behavior as it is.

2) As the actual proposal talks about the permissions of group/others. So, we can add few options as below to the WITH clause

COPY
..
..
WITH 
NO
(READ,WRITE)
PERMISSION TO  
(GROUP,OTHERS)
]

Best Regards,
Dinesh
 
--
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company

Re: Proposing COPY .. WITH PERMISSIVE

From
Robert Haas
Date:
On Thu, Jul 23, 2015 at 8:15 PM, dinesh kumar <dineshkumar02@gmail.com> wrote:
> On Thu, Jul 23, 2015 at 9:21 AM, Robert Haas <robertmhaas@gmail.com> wrote:
>>
>> On Thu, Jul 23, 2015 at 12:19 PM, dinesh kumar <dineshkumar02@gmail.com>
>> wrote:
>> > Sorry for my  unclear description about the proposal.
>> >
>> > "WITH PERMISSIVE" is equal to our existing behavior. That is, chmod=644
>> > on
>> > the created files.
>> >
>> > If User don't specify "PERMISSIVE" as an option, then the chmod=600 on
>> > created files. In this way, we can restrict the other users from reading
>> > these files.
>>
>> There might be some benefit in allowing the user to choose the
>> permissions, but (1) I doubt we want to change the default behavior
>> and (2) providing only two options doesn't seem flexible enough.
>>
>
> Thanks for your inputs Robert.
>
> 1) IMO, we will keep the exiting behavior as it is.
>
> 2) As the actual proposal talks about the permissions of group/others. So,
> we can add few options as below to the WITH clause
>
> COPY
> ..
> ..
> WITH
> [
> NO
> (READ,WRITE)
> PERMISSION TO
> (GROUP,OTHERS)
> ]

If we're going to do anything here, it should use COPY's
extensible-options syntax, I think.

-- 
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company



Re: Proposing COPY .. WITH PERMISSIVE

From
dinesh kumar
Date:


On Fri, Jul 24, 2015 at 10:22 AM, Robert Haas <robertmhaas@gmail.com> wrote:
On Thu, Jul 23, 2015 at 8:15 PM, dinesh kumar <dineshkumar02@gmail.com> wrote:
> On Thu, Jul 23, 2015 at 9:21 AM, Robert Haas <robertmhaas@gmail.com> wrote:
>>
>> On Thu, Jul 23, 2015 at 12:19 PM, dinesh kumar <dineshkumar02@gmail.com>
>> wrote:
>> > Sorry for my  unclear description about the proposal.
>> >
>> > "WITH PERMISSIVE" is equal to our existing behavior. That is, chmod=644
>> > on
>> > the created files.
>> >
>> > If User don't specify "PERMISSIVE" as an option, then the chmod=600 on
>> > created files. In this way, we can restrict the other users from reading
>> > these files.
>>
>> There might be some benefit in allowing the user to choose the
>> permissions, but (1) I doubt we want to change the default behavior
>> and (2) providing only two options doesn't seem flexible enough.
>>
>
> Thanks for your inputs Robert.
>
> 1) IMO, we will keep the exiting behavior as it is.
>
> 2) As the actual proposal talks about the permissions of group/others. So,
> we can add few options as below to the WITH clause
>
> COPY
> ..
> ..
> WITH
> [
> NO
> (READ,WRITE)
> PERMISSION TO
> (GROUP,OTHERS)
> ]

If we're going to do anything here, it should use COPY's
extensible-options syntax, I think.


Thanks Robert. Let me send a patch for this.

Regards,
Dinesh
 
--
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company

Re: Proposing COPY .. WITH PERMISSIVE

From
Stefan Kaltenbrunner
Date:
On 07/25/2015 03:38 AM, dinesh kumar wrote:
> 
> 
> On Fri, Jul 24, 2015 at 10:22 AM, Robert Haas <robertmhaas@gmail.com
> <mailto:robertmhaas@gmail.com>> wrote:
> 
>     On Thu, Jul 23, 2015 at 8:15 PM, dinesh kumar
>     <dineshkumar02@gmail.com <mailto:dineshkumar02@gmail.com>> wrote:
>     > On Thu, Jul 23, 2015 at 9:21 AM, Robert Haas
>     <robertmhaas@gmail.com <mailto:robertmhaas@gmail.com>> wrote:
>     >>
>     >> On Thu, Jul 23, 2015 at 12:19 PM, dinesh kumar
>     <dineshkumar02@gmail.com <mailto:dineshkumar02@gmail.com>>
>     >> wrote:
>     >> > Sorry for my  unclear description about the proposal.
>     >> >
>     >> > "WITH PERMISSIVE" is equal to our existing behavior. That is, chmod=644
>     >> > on
>     >> > the created files.
>     >> >
>     >> > If User don't specify "PERMISSIVE" as an option, then the chmod=600 on
>     >> > created files. In this way, we can restrict the other users from reading
>     >> > these files.
>     >>
>     >> There might be some benefit in allowing the user to choose the
>     >> permissions, but (1) I doubt we want to change the default behavior
>     >> and (2) providing only two options doesn't seem flexible enough.
>     >>
>     >
>     > Thanks for your inputs Robert.
>     >
>     > 1) IMO, we will keep the exiting behavior as it is.
>     >
>     > 2) As the actual proposal talks about the permissions of group/others. So,
>     > we can add few options as below to the WITH clause
>     >
>     > COPY
>     > ..
>     > ..
>     > WITH
>     > [
>     > NO
>     > (READ,WRITE)
>     > PERMISSION TO
>     > (GROUP,OTHERS)
>     > ]
> 
>     If we're going to do anything here, it should use COPY's
>     extensible-options syntax, I think.
> 
> 
> Thanks Robert. Let me send a patch for this.


how are you going to handle windows or unix ACLs here?
Its permission model is quite different and more powerful than (non-acl
based) unix in general, handling this in a flexible way might soon get
very complicated and complex for limited gain...



Stefan



Re: Proposing COPY .. WITH PERMISSIVE

From
dinesh kumar
Date:
On Tue, Sep 1, 2015 at 10:58 PM, Stefan Kaltenbrunner <stefan@kaltenbrunner.cc> wrote:
On 07/25/2015 03:38 AM, dinesh kumar wrote:
>
>
> On Fri, Jul 24, 2015 at 10:22 AM, Robert Haas <robertmhaas@gmail.com
> <mailto:robertmhaas@gmail.com>> wrote:
>
>     On Thu, Jul 23, 2015 at 8:15 PM, dinesh kumar
>     <dineshkumar02@gmail.com <mailto:dineshkumar02@gmail.com>> wrote:
>     > On Thu, Jul 23, 2015 at 9:21 AM, Robert Haas
>     <robertmhaas@gmail.com <mailto:robertmhaas@gmail.com>> wrote:
>     >>
>     >> On Thu, Jul 23, 2015 at 12:19 PM, dinesh kumar
>     <dineshkumar02@gmail.com <mailto:dineshkumar02@gmail.com>>
>     >> wrote:
>     >> > Sorry for my  unclear description about the proposal.
>     >> >
>     >> > "WITH PERMISSIVE" is equal to our existing behavior. That is, chmod=644
>     >> > on
>     >> > the created files.
>     >> >
>     >> > If User don't specify "PERMISSIVE" as an option, then the chmod=600 on
>     >> > created files. In this way, we can restrict the other users from reading
>     >> > these files.
>     >>
>     >> There might be some benefit in allowing the user to choose the
>     >> permissions, but (1) I doubt we want to change the default behavior
>     >> and (2) providing only two options doesn't seem flexible enough.
>     >>
>     >
>     > Thanks for your inputs Robert.
>     >
>     > 1) IMO, we will keep the exiting behavior as it is.
>     >
>     > 2) As the actual proposal talks about the permissions of group/others. So,
>     > we can add few options as below to the WITH clause
>     >
>     > COPY
>     > ..
>     > ..
>     > WITH
>     > [
>     > NO
>     > (READ,WRITE)
>     > PERMISSION TO
>     > (GROUP,OTHERS)
>     > ]
>
>     If we're going to do anything here, it should use COPY's
>     extensible-options syntax, I think.
>
>
> Thanks Robert. Let me send a patch for this.


how are you going to handle windows or unix ACLs here?
Its permission model is quite different and more powerful than (non-acl
based) unix in general, handling this in a flexible way might soon get
very complicated and complex for limited gain...


Hi Stefan,

I had the same questions too. But, I believe, our initdb works in these cases, after creating the data cluster. Isn't ?

Regards,
Dinesh


Stefan

Re: Proposing COPY .. WITH PERMISSIVE

From
Stefan Kaltenbrunner
Date:
On 09/02/2015 10:10 PM, dinesh kumar wrote:
> On Tue, Sep 1, 2015 at 10:58 PM, Stefan Kaltenbrunner
> <stefan@kaltenbrunner.cc <mailto:stefan@kaltenbrunner.cc>> wrote:
> 
>     On 07/25/2015 03:38 AM, dinesh kumar wrote:
>     >
>     >
>     > On Fri, Jul 24, 2015 at 10:22 AM, Robert Haas <robertmhaas@gmail.com <mailto:robertmhaas@gmail.com>
>     > <mailto:robertmhaas@gmail.com <mailto:robertmhaas@gmail.com>>> wrote:
>     >
>     >     On Thu, Jul 23, 2015 at 8:15 PM, dinesh kumar
>     >     <dineshkumar02@gmail.com <mailto:dineshkumar02@gmail.com>
>     <mailto:dineshkumar02@gmail.com <mailto:dineshkumar02@gmail.com>>>
>     wrote:
>     >     > On Thu, Jul 23, 2015 at 9:21 AM, Robert Haas
>     >     <robertmhaas@gmail.com <mailto:robertmhaas@gmail.com>
>     <mailto:robertmhaas@gmail.com <mailto:robertmhaas@gmail.com>>> wrote:
>     >     >>
>     >     >> On Thu, Jul 23, 2015 at 12:19 PM, dinesh kumar
>     >     <dineshkumar02@gmail.com <mailto:dineshkumar02@gmail.com>
>     <mailto:dineshkumar02@gmail.com <mailto:dineshkumar02@gmail.com>>>
>     >     >> wrote:
>     >     >> > Sorry for my  unclear description about the proposal.
>     >     >> >
>     >     >> > "WITH PERMISSIVE" is equal to our existing behavior. That
>     is, chmod=644
>     >     >> > on
>     >     >> > the created files.
>     >     >> >
>     >     >> > If User don't specify "PERMISSIVE" as an option, then the
>     chmod=600 on
>     >     >> > created files. In this way, we can restrict the other
>     users from reading
>     >     >> > these files.
>     >     >>
>     >     >> There might be some benefit in allowing the user to choose the
>     >     >> permissions, but (1) I doubt we want to change the default
>     behavior
>     >     >> and (2) providing only two options doesn't seem flexible
>     enough.
>     >     >>
>     >     >
>     >     > Thanks for your inputs Robert.
>     >     >
>     >     > 1) IMO, we will keep the exiting behavior as it is.
>     >     >
>     >     > 2) As the actual proposal talks about the permissions of
>     group/others. So,
>     >     > we can add few options as below to the WITH clause
>     >     >
>     >     > COPY
>     >     > ..
>     >     > ..
>     >     > WITH
>     >     > [
>     >     > NO
>     >     > (READ,WRITE)
>     >     > PERMISSION TO
>     >     > (GROUP,OTHERS)
>     >     > ]
>     >
>     >     If we're going to do anything here, it should use COPY's
>     >     extensible-options syntax, I think.
>     >
>     >
>     > Thanks Robert. Let me send a patch for this.
> 
> 
>     how are you going to handle windows or unix ACLs here?
>     Its permission model is quite different and more powerful than (non-acl
>     based) unix in general, handling this in a flexible way might soon get
>     very complicated and complex for limited gain...
> 
> 
> Hi Stefan,
> 
> I had the same questions too. But, I believe, our initdb works in these
> cases, after creating the data cluster. Isn't ?

maybe - but having a fixed "default"  is very different from baking a
classic unix permission concept of user/group/world^others into actual
DDL or into a COPY option. The proposed syntax might make some sense to
a admin used to a unix style system but it is likely utterly
incomprehensible to somebody who is used to (windows style) ACLs.

I dont have a good answer on what to do else atm but I dont think we
should embedded traditional/historical unix permission models in our
grammer unless really really needed...


Stefan



Re: Proposing COPY .. WITH PERMISSIVE

From
dinesh kumar
Date:
On Wed, Sep 2, 2015 at 1:19 PM, Stefan Kaltenbrunner <stefan@kaltenbrunner.cc> wrote:
On 09/02/2015 10:10 PM, dinesh kumar wrote:
> On Tue, Sep 1, 2015 at 10:58 PM, Stefan Kaltenbrunner
> <stefan@kaltenbrunner.cc <mailto:stefan@kaltenbrunner.cc>> wrote:
>
>     On 07/25/2015 03:38 AM, dinesh kumar wrote:
>     >
>     >
>     > On Fri, Jul 24, 2015 at 10:22 AM, Robert Haas <robertmhaas@gmail.com <mailto:robertmhaas@gmail.com>
>     > <mailto:robertmhaas@gmail.com <mailto:robertmhaas@gmail.com>>> wrote:
>     >
>     >     On Thu, Jul 23, 2015 at 8:15 PM, dinesh kumar
>     >     <dineshkumar02@gmail.com <mailto:dineshkumar02@gmail.com>
>     <mailto:dineshkumar02@gmail.com <mailto:dineshkumar02@gmail.com>>>
>     wrote:
>     >     > On Thu, Jul 23, 2015 at 9:21 AM, Robert Haas
>     >     <robertmhaas@gmail.com <mailto:robertmhaas@gmail.com>
>     <mailto:robertmhaas@gmail.com <mailto:robertmhaas@gmail.com>>> wrote:
>     >     >>
>     >     >> On Thu, Jul 23, 2015 at 12:19 PM, dinesh kumar
>     >     <dineshkumar02@gmail.com <mailto:dineshkumar02@gmail.com>
>     <mailto:dineshkumar02@gmail.com <mailto:dineshkumar02@gmail.com>>>
>     >     >> wrote:
>     >     >> > Sorry for my  unclear description about the proposal.
>     >     >> >
>     >     >> > "WITH PERMISSIVE" is equal to our existing behavior. That
>     is, chmod=644
>     >     >> > on
>     >     >> > the created files.
>     >     >> >
>     >     >> > If User don't specify "PERMISSIVE" as an option, then the
>     chmod=600 on
>     >     >> > created files. In this way, we can restrict the other
>     users from reading
>     >     >> > these files.
>     >     >>
>     >     >> There might be some benefit in allowing the user to choose the
>     >     >> permissions, but (1) I doubt we want to change the default
>     behavior
>     >     >> and (2) providing only two options doesn't seem flexible
>     enough.
>     >     >>
>     >     >
>     >     > Thanks for your inputs Robert.
>     >     >
>     >     > 1) IMO, we will keep the exiting behavior as it is.
>     >     >
>     >     > 2) As the actual proposal talks about the permissions of
>     group/others. So,
>     >     > we can add few options as below to the WITH clause
>     >     >
>     >     > COPY
>     >     > ..
>     >     > ..
>     >     > WITH
>     >     > [
>     >     > NO
>     >     > (READ,WRITE)
>     >     > PERMISSION TO
>     >     > (GROUP,OTHERS)
>     >     > ]
>     >
>     >     If we're going to do anything here, it should use COPY's
>     >     extensible-options syntax, I think.
>     >
>     >
>     > Thanks Robert. Let me send a patch for this.
>
>
>     how are you going to handle windows or unix ACLs here?
>     Its permission model is quite different and more powerful than (non-acl
>     based) unix in general, handling this in a flexible way might soon get
>     very complicated and complex for limited gain...
>
>
> Hi Stefan,
>
> I had the same questions too. But, I believe, our initdb works in these
> cases, after creating the data cluster. Isn't ?

maybe - but having a fixed "default"  is very different from baking a
classic unix permission concept of user/group/world^others into actual
DDL or into a COPY option. The proposed syntax might make some sense to
a admin used to a unix style system but it is likely utterly
incomprehensible to somebody who is used to (windows style) ACLs.

I dont have a good answer on what to do else atm but I dont think we
should embedded traditional/historical unix permission models in our
grammer unless really really needed..
 
Yes, I agree with you. We shouldn't embed the unix style access model into COPY.

COPY's default behaviour umask 644 on output files, which is giving read access to other users.
I see, there is a good reason behind it. Also, it would be good to have a control on the READ ACCESS of a file, where we can secure our dump files, from the non instance ownership users.

Adding a trivial patch to control this read ACL.

--Sample Test Case

--Default behaviour
postgres=# COPY test_table TO '/tmp/readacs.txt';
COPY 1000

$ ls -l /tmp/readacs.txt
-rw-r--r--  /tmp/test1.txt

--With applied patch
postgres=# COPY test_table TO '/tmp/noreadacs.txt' NO READ ACCESS;
COPY 1000

$ ls -l /tmp/noreadacs.txt
-rw------- /tmp/noreadacs.txt

We can also use "PROGRAM 'cat > Output.csv' " to achieve this "NO READ ACCESS", since the program is always running as a instance owner.

Let me know your inputs and thoughts.

Stefan


--
Attachment

Re: Proposing COPY .. WITH PERMISSIVE

From
Michael Paquier
Date:
On Sat, Oct 3, 2015 at 1:43 PM, dinesh kumar wrote:
> We can also use "PROGRAM 'cat > Output.csv' " to achieve this "NO READ
> ACCESS", since the program is always running as a instance owner.
> Let me know your inputs and thoughts.

That's one way. And as PROGRAM presents the advantage to open the file
before the COPY has begun processing any tuples, the umask would be
set before writing any data to it, hence why complicating COPY with a
new option while we already have something to apply restrictions to
the output file? It seems that this patch is just an unnecessary
complication, and I doubt that we would want to change the default
behavior of 644 that has been here for ages.
-- 
Michael



Re: Proposing COPY .. WITH PERMISSIVE

From
dinesh kumar
Date:
On Thu, Nov 12, 2015 at 4:35 AM, Michael Paquier <michael.paquier@gmail.com> wrote:
On Sat, Oct 3, 2015 at 1:43 PM, dinesh kumar wrote:
> We can also use "PROGRAM 'cat > Output.csv' " to achieve this "NO READ
> ACCESS", since the program is always running as a instance owner.
> Let me know your inputs and thoughts.

That's one way. And as PROGRAM presents the advantage to open the file
before the COPY has begun processing any tuples, the umask would be
set before writing any data to it, hence why complicating COPY with a
new option while we already have something to apply restrictions to
the output file? It seems that this patch is just an unnecessary
complication, and I doubt that we would want to change the default
behavior of 644 that has been here for ages.

Hi Michael,

Thanks for your inputs.

I am also against changing the default behavior. Since, I see, some advantages having 644.

As pg_file_write, and 'PROGRAM' uses it's instance owner umask for the output file, I believe,
we should also have the same umaks for the COPY too. I Could be wrong here, But I don't see
"PROGRAM" as an alternative to this. Since, we have a separate TO clause, which takes care about
dumping data into files.

Let me know, if I'm wrong here.

--
Michael



--

Re: Proposing COPY .. WITH PERMISSIVE

From
Peter Eisentraut
Date:
On 9/2/15 4:19 PM, Stefan Kaltenbrunner wrote:
> maybe - but having a fixed "default"  is very different from baking a
> classic unix permission concept of user/group/world^others into actual
> DDL or into a COPY option. The proposed syntax might make some sense to
> a admin used to a unix style system but it is likely utterly
> incomprehensible to somebody who is used to (windows style) ACLs.
> 
> I dont have a good answer on what to do else atm but I dont think we
> should embedded traditional/historical unix permission models in our
> grammer unless really really needed...

The user can just create a directory with appropriate permissions and
copy the files there.  I don't really see why COPY needs to know about
all this.




Re: Proposing COPY .. WITH PERMISSIVE

From
Michael Paquier
Date:
On Mon, Nov 16, 2015 at 11:05 AM, Peter Eisentraut <peter_e@gmx.net> wrote:
> On 9/2/15 4:19 PM, Stefan Kaltenbrunner wrote:
>> maybe - but having a fixed "default"  is very different from baking a
>> classic unix permission concept of user/group/world^others into actual
>> DDL or into a COPY option. The proposed syntax might make some sense to
>> a admin used to a unix style system but it is likely utterly
>> incomprehensible to somebody who is used to (windows style) ACLs.
>>
>> I dont have a good answer on what to do else atm but I dont think we
>> should embedded traditional/historical unix permission models in our
>> grammer unless really really needed...
>
> The user can just create a directory with appropriate permissions and
> copy the files there.  I don't really see why COPY needs to know about
> all this.

In short, it seems that this patch is better rejected. And I am
planning to do so if there are no complaints.
-- 
Michael



Re: Proposing COPY .. WITH PERMISSIVE

From
Michael Paquier
Date:
On Mon, Nov 16, 2015 at 11:27 AM, Michael Paquier wrote:
> In short, it seems that this patch is better rejected. And I am
> planning to do so if there are no complaints.

OK, done so in the CF app.
Dinesh, please do not be discouraged by that. Everybody has patches
rejected, and I know a bit of it :)
-- 
Michael



Re: Proposing COPY .. WITH PERMISSIVE

From
dinesh kumar
Date:
On Tue, Nov 17, 2015 at 1:02 AM, Michael Paquier <michael.paquier@gmail.com> wrote:
On Mon, Nov 16, 2015 at 11:27 AM, Michael Paquier wrote:
> In short, it seems that this patch is better rejected. And I am
> planning to do so if there are no complaints.

OK, done so in the CF app.
Dinesh, please do not be discouraged by that. Everybody has patches
rejected, and I know a bit of it :)

Sure Michael :-)

Thanks. 
--
Michael



--