Thread: Proposing COPY .. WITH PERMISSIVE
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
Dinesh
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
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.
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
Hi Robert/Andres,
On Thu, Jul 23, 2015 at 8:34 AM, Robert Haas <robertmhaas@gmail.com> wrote:
That doesn't sound like an especially good idea. What if I want mode 770?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.
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
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
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
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
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
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
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>>how are you going to handle windows or unix ACLs here?> >> 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.
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
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
On Wed, Sep 2, 2015 at 1:19 PM, Stefan Kaltenbrunner <stefan@kaltenbrunner.cc> wrote:
Yes, I agree with you. We shouldn't embed the unix style access model into COPY.
--
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>>>maybe - but having a fixed "default" is very different from baking a> > >> 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 ?
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.
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
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
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
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
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
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.
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
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
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