Jim Nasby asked:
What do people think about the Oracle method where bulk data operations
can only occur in a specified directory? Making that restriction mightaddress some of the security concerns. I don't think we should changeCOPY in such a way that you *have* to use a specified directory, but i
On Tue, Aug 30, 2005 at 11:20:49PM -0400, Greg Stark wrote:
> Scott Marlowe <[EMAIL PROTECTED]> writes:
>
> > Plus, how is the server supposed to KNOW that you have access to the
> > file? psql may know who you are, but the server only knows who you are
> > in the "postgresql" sense, not the OS s
Scott Marlowe <[EMAIL PROTECTED]> writes:
> Plus, how is the server supposed to KNOW that you have access to the
> file? psql may know who you are, but the server only knows who you are
> in the "postgresql" sense, not the OS sense.
My original suggestion was that clients connected via unix doma
Greg Stark <[EMAIL PROTECTED]> writes:
> Alternatively and actually even better and more secure would be
> passing the fd directly from the client to the server over the socket.
Sure ... on the platforms that support that, for the connection types
for which they support it. But I think that in th
Greg Stark <[EMAIL PROTECTED]> writes:
> I was only suggesting using this from a local unix user where you can
> actually authoritatively say something about the uid of the connecting
> user. I suggested that if the owner of the file matches the uid of the
> connecting user (which you can get on a
Tom Lane <[EMAIL PROTECTED]> writes:
> Greg Stark <[EMAIL PROTECTED]> 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 penal
"John D. Burger" <[EMAIL PROTECTED]> writes:
> >> Well, they would have access to every world readable file on the
> >> system, ie /etc, /usr, /lib, ... most files are world readable. There's
> >> a lot of discussion about this, yet no-one has demonstrated that COPY
> >> FROM STDIN isn't just as
Well, they would have access to every world readable file on the
system, ie /etc, /usr, /lib, ... most files are world readable.
There's
a lot of discussion about this, yet no-one has demonstrated that COPY
FROM STDIN isn't just as good and avoids all the issues entirely.
Well they're world-re
Greg Stark <[EMAIL PROTECTED]> 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
Martijn van Oosterhout writes:
> There's a lot of discussion about this, yet no-one has demonstrated that
> COPY FROM STDIN isn't just as good and avoids all the issues entirely.
In any case here's some quick results from my system. There seems to a greater
than 21% slowdown associated with pipi
Martijn van Oosterhout writes:
> On Sat, Aug 27, 2005 at 01:20:29AM -0400, Greg Stark wrote:
> > For that matter it might be handy to be able to grant permission to regular
> > users to load or dump files to arbitrary locations. The security
> > consequences
> > would have to be documented but I
On Sat, Aug 27, 2005 at 01:20:29AM -0400, Greg Stark wrote:
> > Of course that method only applies to a subset of PG users, and
> > completely excludes the Windows side. It might also conflict with
> > security policies that forbid PG from reading and writing outside its
> > own data directory.
>
Douglas McNaught <[EMAIL PROTECTED]> writes:
> Greg Stark <[EMAIL PROTECTED]> writes:
>
> > If you're connected via a unix domain socket we can know the UID of the
> > client
> > end. I don't see reproducing the entire unix semantics but if file is owned
> > by
> > the same uid as the user conn
On Fri, Aug 26, 2005 at 06:04:52PM -0400, Greg Stark wrote:
> Douglas McNaught <[EMAIL PROTECTED]> writes:
>
> > You can use \copy in 'psql' on the client side, but you have to be a
> > superuser to do COPY on the server side, for security reasons.
>
> I wonder if there's any way to relax this co
Greg Stark <[EMAIL PROTECTED]> writes:
> Douglas McNaught <[EMAIL PROTECTED]> writes:
>
>> You can use \copy in 'psql' on the client side, but you have to be a
>> superuser to do COPY on the server side, for security reasons.
>
> I wonder if there's any way to relax this constraint.
>
> If you're
Douglas McNaught <[EMAIL PROTECTED]> writes:
> You can use \copy in 'psql' on the client side, but you have to be a
> superuser to do COPY on the server side, for security reasons.
I wonder if there's any way to relax this constraint.
If you're connected via a unix domain socket we can know th
Emi Lu <[EMAIL PROTECTED]> writes:
> Greetings,
>
> I met a question about Copy. I tried to run :
>copy test(studid) from '/myownDIR/a.txt';
>
> But I got an error as the following:
> ERROR: must be *superuser* to COPY to or from a file
>
> May I know is it possible that instead of supervuser
Greetings,
I met a question about Copy. I tried to run :
copy test(studid) from '/myownDIR/a.txt';
But I got an error as the following:
ERROR: must be *superuser* to COPY to or from a file
May I know is it possible that instead of supervuser, regular users are
able to use COPY as well?
T
18 matches
Mail list logo
