Re: Directory/File Access Permissions for COPY and Generic File Access Functions - Mailing list pgsql-hackers

From Robert Haas
Subject Re: Directory/File Access Permissions for COPY and Generic File Access Functions
Date
Msg-id CA+TgmoY8p2w1qVXwkM3yO0Cdj7uES6b_iWYiOBLTFepTwCJ9iw@mail.gmail.com
Whole thread Raw
In response to Re: Directory/File Access Permissions for COPY and Generic File Access Functions  (Andres Freund <andres@2ndquadrant.com>)
Responses Re: Directory/File Access Permissions for COPY and Generic File Access Functions
Re: Directory/File Access Permissions for COPY and Generic File Access Functions
List pgsql-hackers
On Wed, Oct 29, 2014 at 10:52 AM, Andres Freund <andres@2ndquadrant.com> wrote:
>> The larger point though is that this is just one of innumerable attack
>> routes for anyone with the ability to make the server do filesystem reads
>> or writes of his choosing.  If you think that's something you can safely
>> give to people you don't trust enough to make them superusers, you are
>> wrong, and I don't particularly want to spend the next ten years trying
>> to wrap band-aids around your misjudgment.
>
> ... but that doesn't necessarily address this point.

I think the question is "just how innumerable are those attack
routes"?  So, we can prevent a symlink from being used via O_NOFOLLOW.
But what about hard links?

In general, the hazard is that an untrusted user can induce the user
to read or write a file that the user in question could not have read
or written himself.  It's not clear to me whether it's reasonably
possible to build a system that is robust against such attacks, or
not.

-- 
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company



pgsql-hackers by date:

Previous
From: Andres Freund
Date:
Subject: Re: Directory/File Access Permissions for COPY and Generic File Access Functions
Next
From: Stephen Frost
Date:
Subject: Re: Directory/File Access Permissions for COPY and Generic File Access Functions