Re: About "ERROR: must be *superuser* to COPY to or from a file" - Mailing list pgsql-general

From Greg Stark
Subject Re: About "ERROR: must be *superuser* to COPY to or from a file"
Date
Msg-id 878xyk5uie.fsf@stark.xeocode.com
Whole thread Raw
In response to Re: About "ERROR: must be *superuser* to COPY to or from a file"  (Tom Lane <tgl@sss.pgh.pa.us>)
List pgsql-general
Tom Lane <tgl@sss.pgh.pa.us> writes:

> Greg Stark <gsstark@mit.edu> writes:
> > In any case here's some quick results from my system. There seems to a greater
> > than 21% slowdown associated with piping the data through two processes
> > instead of reading directly.
>
> Well, if the penalty is order of 20% (as opposed to integer multiples)
> I think the discussion is over.  We're not going to introduce arguable
> security holes for that sort of gain --- there are other places we could
> find that much speedup for much less risk.

Well it's not like it's an either or thing. a 40% speed increase would be even
better.

I can't see how letting users read files they own can possibly be a security
hole. The only case would be if there are files they own in directories they
don't have access to read. Which would be a pretty strange circumstance.

I could see saying it's not worth the effort to implement it. (Though what I
suggested would be a pretty simple patch.) So if I went and implemented it
and/or the solution based on passing an fd to the server would it be accepted
(assuming the code quality was up to snuff)?

> (BTW, were you testing CVS tip or 8.0?  The recent COPY FROM speedup
> patch would have affected this test.)

No. Actually sadly this is 7.4.

I would expect the parsing changes to help in either case though, no?
In any case my test was pretty unscientific. I just wanted to say it's not
going to be zero effect.

--
greg

pgsql-general by date:

Previous
From: Greg Stark
Date:
Subject: Re: About "ERROR: must be *superuser* to COPY to or from a file"
Next
From: Martijn van Oosterhout
Date:
Subject: Re: Select gives the wrong results