> On Nov 10, 2017, at 3:58 PM, Stephen Frost wrote:
>
> Michael, Tom,
>
> * Michael Paquier (michael.paqu...@gmail.com) wrote:
>> On Fri, Nov 10, 2017 at 10:00 AM, Tom Lane wrote:
>>> Stephen Frost writes:
I'm guessing no, which essentially means that *we* consider access to
lo_impo
Stephen Frost writes:
> * Michael Paquier (michael.paqu...@gmail.com) wrote:
>> Forcing an admin to give full superuser rights to one user willing to
>> work only on LOs import and export is a wrong concept.
> The problem I have with this is that 'full superuser rights' actually
> are being grant
On Sat, Nov 11, 2017 at 12:50 AM, Robert Haas wrote:
> On Fri, Nov 10, 2017 at 10:34 AM, Tom Lane wrote:
>> I think as far as that goes, we can just change to "Therefore, by default
>> their use is restricted ...". Then I suggest adding a para
>> after that, with wording along the lines of
>>
>
Michael, Tom,
* Michael Paquier (michael.paqu...@gmail.com) wrote:
> On Fri, Nov 10, 2017 at 10:00 AM, Tom Lane wrote:
> > Stephen Frost writes:
> >> I'm guessing no, which essentially means that *we* consider access to
> >> lo_import/lo_export to be equivilant to superuser and therefore we're
>
On Fri, Nov 10, 2017 at 10:34 AM, Tom Lane wrote:
> I think as far as that goes, we can just change to "Therefore, by default
> their use is restricted ...". Then I suggest adding a para
> after that, with wording along the lines of
>
> It is possible to GRANT use of server-side lo_import an
Michael Paquier writes:
> That will not sound much as a surprise as I spawned the original
> thread, but like Robert I understand that getting rid of all superuser
> checks is a goal that we are trying to reach to allow admins to have
> more flexibility in handling permissions to a subset of objec
On Fri, Nov 10, 2017 at 10:00 AM, Tom Lane wrote:
> Stephen Frost writes:
>> I'm guessing no, which essentially means that *we* consider access to
>> lo_import/lo_export to be equivilant to superuser and therefore we're
>> not going to implement anything to try and prevent the user who has
>> acc
Stephen Frost writes:
> I'm guessing no, which essentially means that *we* consider access to
> lo_import/lo_export to be equivilant to superuser and therefore we're
> not going to implement anything to try and prevent the user who has
> access to those functions from becoming superuser. If we ar
Robert,
* Robert Haas (robertmh...@gmail.com) wrote:
> On Thu, Nov 9, 2017 at 2:56 PM, Stephen Frost wrote:
> > Further, I agree entirely that we
> > shouldn't be deciding that certain capabilities are never allowed to be
> > given to a user- but that's why superuser *exists* and why it's possibl
Michael Paquier writes:
> On Fri, Nov 10, 2017 at 7:05 AM, Tom Lane wrote:
>> I did miss the need to fix the docs, and am happy to put in some strong
>> wording about the security hazards of these functions while fixing the
>> docs. But I do not think that leaving them with hardwired superuser
>
On Fri, Nov 10, 2017 at 7:05 AM, Tom Lane wrote:
> I did miss the need to fix the docs, and am happy to put in some strong
> wording about the security hazards of these functions while fixing the
> docs. But I do not think that leaving them with hardwired superuser
> checks is an improvement over
Robert Haas writes:
> On Thu, Nov 9, 2017 at 2:56 PM, Stephen Frost wrote:
>> Further, I agree entirely that we
>> shouldn't be deciding that certain capabilities are never allowed to be
>> given to a user- but that's why superuser *exists* and why it's possible
>> to give superuser access to mul
On Thu, Nov 9, 2017 at 2:56 PM, Stephen Frost wrote:
> I agree that it may not be obvious which cases lead to a relatively easy
> way to obtain superuser and which don't, and that's actually why I'd
> much rather it be something that we're considering and looking out for
> because, frankly, we're
Robert,
* Robert Haas (robertmh...@gmail.com) wrote:
> On Thu, Nov 9, 2017 at 1:52 PM, Stephen Frost wrote:
> > This is not unlike the discussions we've had in the past around allowing
> > non-owners of a table to modify properties of a table, where the
> > argument has been successfully and clea
On Thu, Nov 9, 2017 at 1:52 PM, Stephen Frost wrote:
>> I disagree that that is, or should be, a guiding principle.
>
> It was what I was using as the basis of the work which I did in this
> area and, at least at that time, there seemed to be little issue with
> that.
Well, there actually kind of
Robert,
* Robert Haas (robertmh...@gmail.com) wrote:
> On Thu, Nov 9, 2017 at 1:16 PM, Stephen Frost wrote:
> > While we have been working to reduce the number of superuser() checks in
> > the backend in favor of having the ability to GRANT explicit rights, one
> > of the guideing principles has
On Thu, Nov 9, 2017 at 1:16 PM, Stephen Frost wrote:
> While we have been working to reduce the number of superuser() checks in
> the backend in favor of having the ability to GRANT explicit rights, one
> of the guideing principles has always been that capabilities which can
> be used to gain supe
Tom, Michael,
* Tom Lane (t...@sss.pgh.pa.us) wrote:
> Michael Paquier writes:
> > On Thu, Nov 9, 2017 at 6:05 AM, Tom Lane wrote:
> >> Another idea would be to invent a new external flag bit "INV_WRITE_ONLY",
> >> so that people who wanted true write-only could get it, without breaking
> >> bac
Michael Paquier writes:
> On Thu, Nov 9, 2017 at 6:05 AM, Tom Lane wrote:
>> Another idea would be to invent a new external flag bit "INV_WRITE_ONLY",
>> so that people who wanted true write-only could get it, without breaking
>> backwards-compatible behavior. But I'm inclined to wait for some f
On Thu, Nov 9, 2017 at 6:05 AM, Tom Lane wrote:
> Michael Paquier writes:
>> On Tue, Sep 26, 2017 at 11:42 AM, Vaishnavi Prabakaran
>> wrote:
>>> I moved the cf entry to "ready for committer", and though my vote is for
>>> keeping the existing API behavior with write implying read, I let the
>>>
Michael Paquier writes:
> On Tue, Sep 26, 2017 at 11:42 AM, Vaishnavi Prabakaran
> wrote:
>> I moved the cf entry to "ready for committer", and though my vote is for
>> keeping the existing API behavior with write implying read, I let the
>> committer decide whether the following behavior change
On Tue, Sep 26, 2017 at 11:42 AM, Vaishnavi Prabakaran
wrote:
> I moved the cf entry to "ready for committer", and though my vote is for
> keeping the existing API behavior with write implying read, I let the
> committer decide whether the following behavior change is Ok or not.
> "Reading from a
On Tue, Sep 26, 2017 at 11:45 AM, Michael Paquier wrote:
> On Tue, Sep 26, 2017 at 9:04 AM, Vaishnavi Prabakaran
> wrote:
> > Yes, I did realize on further reading the patch and what led to the
> > confusion is that in the 3rd patch , updated documentation(copied below)
> > still says that readi
On Tue, Sep 26, 2017 at 9:04 AM, Vaishnavi Prabakaran
wrote:
> Yes, I did realize on further reading the patch and what led to the
> confusion is that in the 3rd patch , updated documentation(copied below)
> still says that reading from a descriptor opened with INV_WRITE is possible.
> I think we
Hi,
On Tue, Sep 19, 2017 at 5:12 PM, Michael Paquier
wrote:
>
> >>@@ -163,22 +150,16 @@ lo_read(int fd, char *buf, int len)
> >>
> >> + if ((lobj->flags & IFS_RDLOCK) == 0)
> >>+ ereport(ERROR,
> >>+ (errcode(ERRCODE_OBJECT_NOT_IN_PREREQUISITE_STATE),
> >>+ errmsg("large object descriptor %
On Tue, Sep 19, 2017 at 1:24 PM, Vaishnavi Prabakaran
wrote:
> On Mon, Aug 14, 2017, Michael Paquier wrote:
>>Attached is a set of 3 patches:
>
> I tried to review the patch and firstly patch applies cleanly without any
> noise.
Thanks for the review, Vaishnavi.
>>- 0001 removes ALLOW_DANGEROUS
Hi,
On Mon, Aug 14, 2017, Michael Paquier wrote:
>Attached is a set of 3 patches:
I tried to review the patch and firstly patch applies cleanly without any
noise.
>- 0001 removes ALLOW_DANGEROUS_LO_FUNCTIONS
I think it is better to remove "ALLOW_DANGEROUS_LO_FUNCTIONS" from
pg_config_manual.
On Tue, Aug 15, 2017 at 10:35 PM, Robert Haas wrote:
> +1 for 0001 and 0002 in general, but I can't help noticing that they
> lead to a noticeable worsening of the error messages in the regression
> tests.
As the access restriction gets handled by GRANT in this patch, that's
a price to pay. The v
On Sun, Aug 13, 2017 at 11:20 PM, Michael Paquier
wrote:
> Recent commit 8d98819 has added a missing permissoin check to lo_put()
> to make sure that the write permissions of the object are properly set
> before writing to a large object. When studying the problem, we bumped
> into the fact that i
Hi all,
Recent commit 8d98819 has added a missing permissoin check to lo_put()
to make sure that the write permissions of the object are properly set
before writing to a large object. When studying the problem, we bumped
into the fact that it is possible to actually simplify those ACL
checks and r
30 matches
Mail list logo