Bernard wrote:
> 1) Add optional Postgresql user permission to use the COPY command
> with files.
>
> or
>
> 2) Split up security risk calculations between the two directions "TO"
> and "FROM" and relax security. Look at MySQL for clues. The
> application developer can manage security on file system permission
> level.
Could you be more specific rather than sending me on a random trawl
through the documentation of software I'm not familiar with?
The issue is that COPY FROM will read any file that the backend user can
access, so allowing it is equivalent to allowing read access to all data
in the database, including configuration and access control information,
plus whatever other files you happen to be able to read on the system:
testbulk=# create temporary table haxxor(line text);
CREATE TABLE
testbulk=# copy haxxor from '/etc/passwd';
COPY
testbulk=# select * from haxxor;
line
-------------------------------------------------------------------
root:x:0:0:root:/root:/bin/bash
bin:x:1:1:bin:/bin:/bin/false
[...]
I don't see how splitting up the checks for COPY FROM vs COPY TO helps.
> 3) Close the ident loop in such a way that if a Postgresql user was
> granted access via ident as an operating system user then the COPY
> command is executed as a process with that user ID and not as postgres
> superuser.
The backend doesn't run as root so it can't seteuid().
> Option 3) would possibly open a can of worms, especially because there
> are already unresolved authentication issues with ident and Java.
What are the unresolved issues here? I haven't seen any reports on the
JDBC list beyond some older IPV6-related problems which are easy enough
to work around.
-O