Re: [HACKERS] Simplify ACL handling for large objects and removal of superuser() checks

> 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,

Re: [HACKERS] Simplify ACL handling for large objects and removal of superuser() checks

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'

Re: [HACKERS] Simplify ACL handling for large objects and removal of superuser() checks

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 >>

Re: [HACKERS] Simplify ACL handling for large objects and removal of superuser() checks

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

Re: [HACKERS] Simplify ACL handling for large objects and removal of superuser() checks

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

Re: [HACKERS] Simplify ACL handling for large objects and removal of superuser() checks

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

Re: [HACKERS] Simplify ACL handling for large objects and removal of superuser() checks

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

Re: [HACKERS] Simplify ACL handling for large objects and removal of superuser() checks

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

Re: [HACKERS] Simplify ACL handling for large objects and removal of superuser() checks

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*

Re: [HACKERS] Simplify ACL handling for large objects and removal of superuser() checks

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

Re: [HACKERS] Simplify ACL handling for large objects and removal of superuser() checks

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

Re: [HACKERS] Simplify ACL handling for large objects and removal of superuser() checks

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

Re: [HACKERS] Simplify ACL handling for large objects and removal of superuser() checks

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 >

Re: [HACKERS] Simplify ACL handling for large objects and removal of superuser() checks

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

Re: [HACKERS] Simplify ACL handling for large objects and removal of superuser() checks

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,

Re: [HACKERS] Simplify ACL handling for large objects and removal of superuser() checks

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

Re: [HACKERS] Simplify ACL handling for large objects and removal of superuser() checks

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 >

Re: [HACKERS] Simplify ACL handling for large objects and removal of superuser() checks

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

Re: [HACKERS] Simplify ACL handling for large objects and removal of superuser() checks

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 >>

Re: [HACKERS] Simplify ACL handling for large objects and removal of superuser() checks

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

Re: [HACKERS] Simplify ACL handling for large objects and removal of superuser() checks

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

Re: [HACKERS] Simplify ACL handling for large objects and removal of superuser() checks

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

Re: [HACKERS] Simplify ACL handling for large objects and removal of superuser() checks

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 ,

Re: [HACKERS] Simplify ACL handling for large objects and removal of superuser() checks

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

Re: [HACKERS] Simplify ACL handling for large objects and removal of superuser() checks

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), > >>+

Re: [HACKERS] Simplify ACL handling for large objects and removal of superuser() checks

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

Re: [HACKERS] Simplify ACL handling for large objects and removal of superuser() checks

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

Re: [HACKERS] Simplify ACL handling for large objects and removal of superuser() checks

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,

Re: [HACKERS] Simplify ACL handling for large objects and removal of superuser() checks

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