Re: About "ERROR: must be *superuser* to COPY to or from a file"
От | Greg Stark |
---|---|
Тема | Re: About "ERROR: must be *superuser* to COPY to or from a file" |
Дата | |
Msg-id | 878xyk5uie.fsf@stark.xeocode.com обсуждение исходный текст |
Ответ на | Re: About "ERROR: must be *superuser* to COPY to or from a file" (Tom Lane <tgl@sss.pgh.pa.us>) |
Список | 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 по дате отправления: