Re: Directory/File Access Permissions for COPY and Generic File Access Functions

From: Stephen Frost <sfrost(at)snowman(dot)net>
To: Robert Haas <robertmhaas(at)gmail(dot)com>
Cc: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>, Andres Freund <andres(at)2ndquadrant(dot)com>, Adam Brightwell <adam(dot)brightwell(at)crunchydatasolutions(dot)com>, Peter Eisentraut <peter_e(at)gmx(dot)net>, PostgreSQL Hackers <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: Directory/File Access Permissions for COPY and Generic File Access Functions
Date: 2014-10-29 21:08:32
Message-ID: 20141029210832.GB28859@tamriel.snowman.net
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

* Robert Haas (robertmhaas(at)gmail(dot)com) wrote:
> On Wed, Oct 29, 2014 at 3:31 PM, Stephen Frost <sfrost(at)snowman(dot)net> wrote:
> > I still don't particularly like it and, frankly, the limitations we've
> > come up with thus far are not issues for my use-cases and I'd rather
> > have them and be able to say "yes, you can use this with some confidence
> > that it won't trivially bypass the DB security or provide a way to crash
> > the DB".
>
> I think it *will* trivially bypass the DB security. If trivial means
> "it can be done by anyone with no work at all", then, OK, it's not
> trivial. If it means "it can be done by a reasonably skilled engineer
> without too much trouble", then it's trivial. To call it a security
> feature, I think the bar needs to be higher than that.

ENOPARSE

I agree- to be a security feature, we need to have a bar higher than
"can be bypassed by a reasonably skilled engineer without too much
trouble" and certainly higher than "it can be done by anyone with no
work at all". I admit that I didn't realize the situation was quite
so dire today when it comes to these operations and that most utilities
which have to do this for their operations (procmail, maildrop, cron,
etc) have punted completely and gone to using setuid() instead.

Although I will note that cron, at least, does use O_NOFOLLOW and then
does do the hard-link check with fstat() after the crontab file is
opened. If we're able to identify an issue with this approach, we
should probably let them know.

Another interesting idea might be to have "owner" specified along with
the directory alias and then test that the file to be opened is owned by
that owner, as cron checks..

Perhaps I should go work on Kerberos credential proxying and then we
could at least support this kind of capability on Windows when using
Windows Authentication (eg: Kerberos) and Windows file shares, as SQL
Server does. I'll have to investigate how that works (if it does at
all) with Kerberos-based NFSv4; I haven't run into a system which uses
credential proxying to access NFS yet though I don't see any particular
reason offhand why it wouldn't work.

Thanks,

Stephen

In response to

Browse pgsql-hackers by date

  From Date Subject
Next Message Marko Tiikkaja 2014-10-29 21:12:05 Re: Support UPDATE table SET(*)=...
Previous Message Andres Freund 2014-10-29 20:58:11 Re: pg_background (and more parallelism infrastructure patches)