I'm marking this as "Rejected" in the commitfest. It's quite clear that
this isn't going to fly in its current form.
For the COPY FROM use case, I'd suggest just doing COPY FROM STDIN. Yes,
it's slower, but not much. And you probably could optimize it further -
there's some gratuitous memcpy()
On 10/29/14 3:41 PM, Jim Nasby wrote:
> On 10/29/14, 2:33 PM, Tom Lane wrote:
>> Capture the postmaster log. Keep on capturing it till somebody
>> fat-fingers their login to the extent of swapping the username and
>> password (yeah, I've done that, haven't you?).
>
> Which begs the question: why
Tom Lane wrote:
> If you are letting untrustworthy people read the postmaster log
> you've already got security problems, as per other recent
> threads.
That seems like a rather naive perspective. In a large operation
there are different roles. To draw some analogies, you might trust
your atto
* Robert Haas (robertmh...@gmail.com) wrote:
> On Wed, Oct 29, 2014 at 3:31 PM, Stephen Frost 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 us
* Tom Lane (t...@sss.pgh.pa.us) wrote:
> Stephen Frost writes:
> > * Tom Lane (t...@sss.pgh.pa.us) wrote:
> >> If your ETL process can be restricted that much, can't it use file_fdw or
> >> some such to access a fixed filename set by somebody with more privilege?
>
> > We currently have the ETL f
On Wed, Oct 29, 2014 at 3:31 PM, Stephen Frost 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
Stephen Frost writes:
> * Tom Lane (t...@sss.pgh.pa.us) wrote:
>> If your ETL process can be restricted that much, can't it use file_fdw or
>> some such to access a fixed filename set by somebody with more privilege?
> We currently have the ETL figure out what the filename is on a daily
> basis a
* Tom Lane (t...@sss.pgh.pa.us) wrote:
> Stephen Frost writes:
> > This "ad-hoc data load for Joe" use-case isn't where I had been going
> > with this feature, and I do trust the ETL processes that are behind the
> > use-case that I've proposed for the most part, but there's also no
> > reason for
Stephen Frost writes:
> This "ad-hoc data load for Joe" use-case isn't where I had been going
> with this feature, and I do trust the ETL processes that are behind the
> use-case that I've proposed for the most part, but there's also no
> reason for those files to be symlinks or have hard-links or
* Tom Lane (t...@sss.pgh.pa.us) wrote:
> Well, the issues we've thought of so far require that the attacker have
> his own shell-level access to the filesystem, but I would not like to
> posit that there are none that don't require it. Race conditions, for
> example, could be exploited without a s
On 10/29/14, 2:33 PM, Tom Lane wrote:
Capture the postmaster log. Keep on capturing it till somebody
fat-fingers their login to the extent of swapping the username and
password (yeah, I've done that, haven't you?).
Which begs the question: why on earth do we log passwords at all? This is a
pr
Stephen Frost writes:
> * Kevin Grittner (kgri...@ymail.com) wrote:
>> What's interesting and disappointing here is that not one of these
>> suggested vulnerabilities seems like a possibility on a database
>> server managed in what I would consider a sane and secure manner[1].
> For my part- I ag
* Tom Lane (t...@sss.pgh.pa.us) wrote:
> So heaven help you if you grant user joe access in directory
> /home/joe/copydata, or any other directory whose parent is writable by
> him. He can just remove the directory and replace it with a symlink to
> whatever directory contains files he'd like the
Kevin,
* Kevin Grittner (kgri...@ymail.com) wrote:
> Tom Lane wrote:
> > So at this point we've decided that we must forbid access to symlinked or
> > hardlinked files, which is a significant usability penalty; we've also
> > chosen to blow off most older platforms entirely; and we've only spent
I wrote:
> ... and we've only spent
> about five minutes actually looking for security issues, with no good
> reason to assume there are no more.
Oh, here's another one: what I read in RHEL6's open(2) man page is
O_NOFOLLOW
If pathname is a symbolic link, then the open fails.
Tom Lane wrote:
> So at this point we've decided that we must forbid access to symlinked or
> hardlinked files, which is a significant usability penalty; we've also
> chosen to blow off most older platforms entirely; and we've only spent
> about five minutes actually looking for security issues,
Andres Freund writes:
> On 2014-10-29 16:38:44 +, Jeremy Harris wrote:
>> On 29/10/14 16:11, Andres Freund wrote:
>>> I do think checking the link count to
>>> be 1 is safe though.
>> You will fail against certain styles of online-backup.
> Meh. I don't think that's really a problem for the
Stephen Frost writes:
> * Tom Lane (t...@sss.pgh.pa.us) wrote:
>> This points up the fact that platform-specific security holes are likely
>> to be a huge part of the problem. I won't even speculate about our odds
>> of building something that's secure on Windows.
> Andres' suggestion to only pr
* Jeremy Harris (j...@wizmail.org) wrote:
> On 29/10/14 16:11, Andres Freund wrote:
> > I do think checking the link count to
> > be 1 is safe though.
>
> You will fail against certain styles of online-backup.
Fail-safe though, no? For my part, I'm not particularly bothered by
that; we'd have t
On 2014-10-29 16:38:44 +, Jeremy Harris wrote:
> On 29/10/14 16:11, Andres Freund wrote:
> > I do think checking the link count to
> > be 1 is safe though.
>
> You will fail against certain styles of online-backup.
Meh. I don't think that's really a problem for the usecases for COPY
FROM.
G
On 29/10/14 16:11, Andres Freund wrote:
> I do think checking the link count to
> be 1 is safe though.
You will fail against certain styles of online-backup.
--
Cheers,
Jeremy
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http:/
On Wed, Oct 29, 2014 at 12:36 PM, Adam Brightwell
wrote:
> Robert,
>
>> To articular my own concerns perhaps a bit better, there are two major
>> things I don't like about the whole DIRALIAS proposal. Number one,
>> you're creating this SQL object whose name is not actually used for
>> anything o
Adam,
* Adam Brightwell (adam.brightw...@crunchydatasolutions.com) wrote:
> Pardon my ignorance, but can you help me understand the advantage of not
> having absolute path names in the COPY command?
If you're writing ETL processes and/or PL/PgSQL code which embeds the
COPY command and you migrate
Alvaro,
I think it would make more sense if the file-accessing command specified
> the DIRALIAS (or DIRECTORY, whatever we end up calling this) and a
> pathname relative to the base one. Something like
>
> postgres=# CREATE DIRECTORY logdir ALIAS FOR '/pgsql/data/pg_log';
Following this, what d
Robert,
> To articular my own concerns perhaps a bit better, there are two major
> things I don't like about the whole DIRALIAS proposal. Number one,
> you're creating this SQL object whose name is not actually used for
> anything other than manipulating the alias you created. The users are
> s
* Tom Lane (t...@sss.pgh.pa.us) wrote:
> This points up the fact that platform-specific security holes are likely
> to be a huge part of the problem. I won't even speculate about our odds
> of building something that's secure on Windows.
Andres' suggestion to only provide it on platforms which su
Stephen Frost writes:
> * Tom Lane (t...@sss.pgh.pa.us) wrote:
>> No such file in RHEL 6.6 :-(.
> Ouch. Although- have you tested when happens there?
Pretty much exactly the same thing I just saw on OSX, ie, nothing.
[tgl@sss1 zzz]$ touch foo
[tgl@sss1 zzz]$ ls -l
total 0
-rw-rw-r--. 1 tgl tgl
* Tom Lane (t...@sss.pgh.pa.us) wrote:
> Stephen Frost writes:
> > * Alvaro Herrera (alvhe...@2ndquadrant.com) wrote:
> >> Users cannot create a hard link to a file they can't already access.
>
> > The specifics actually depend on (on Linux, at least) the value of
> > /proc/sys/fs/protected_hardl
Stephen Frost writes:
> * Alvaro Herrera (alvhe...@2ndquadrant.com) wrote:
>> Users cannot create a hard link to a file they can't already access.
> The specifics actually depend on (on Linux, at least) the value of
> /proc/sys/fs/protected_hardlink, which has existed in upstream since 3.6
> (not
On 2014-10-29 12:09:00 -0400, Tom Lane wrote:
> Stephen Frost writes:
> > * Robert Haas (robertmh...@gmail.com) wrote:
> >> 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?
>
* Andres Freund (and...@2ndquadrant.com) wrote:
> On 2014-10-29 12:03:54 -0400, Robert Haas wrote:
> > I don't see how you can draw an arbitrary line there. We either
> > guarantee that the logged-in user can't usurp the server's
> > permissions, or we don't. Making it happen only sometimes in ca
Stephen Frost writes:
> * Robert Haas (robertmh...@gmail.com) wrote:
>> 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?
> You can't hard link to files you don't own.
That restri
On 2014-10-29 12:03:54 -0400, Robert Haas wrote:
> >> And it
> >> still doesn't protect against the case where you hardlink to a file
> >> and then the permissions on that file are later changed.
> >
> > Imo that's simply not a problem that we need to solve - it's much more
> > general and independ
On Wed, Oct 29, 2014 at 12:00 PM, Andres Freund wrote:
> It's possible to do this securely by doing a fstat() and checking the
> link count.
Good point.
>> And it
>> still doesn't protect against the case where you hardlink to a file
>> and then the permissions on that file are later changed.
>
On 2014-10-29 11:52:43 -0400, Robert Haas wrote:
> On Wed, Oct 29, 2014 at 11:34 AM, Stephen Frost wrote:
> > The specifics actually depend on (on Linux, at least) the value of
> > /proc/sys/fs/protected_hardlink, which has existed in upstream since 3.6
> > (not sure about the RHEL kernels, though
On Wed, Oct 29, 2014 at 11:34 AM, Stephen Frost wrote:
> The specifics actually depend on (on Linux, at least) the value of
> /proc/sys/fs/protected_hardlink, which has existed in upstream since 3.6
> (not sure about the RHEL kernels, though I expect they've incorporated
> it also at some point al
Stephen Frost writes:
> * Tom Lane (t...@sss.pgh.pa.us) 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
* Alvaro Herrera (alvhe...@2ndquadrant.com) wrote:
> Robert Haas wrote:
> > On Wed, Oct 29, 2014 at 10:52 AM, Andres Freund
> > 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
> >
Robert Haas wrote:
> On Wed, Oct 29, 2014 at 10:52 AM, Andres Freund
> 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 y
* Robert Haas (robertmh...@gmail.com) wrote:
> On Wed, Oct 29, 2014 at 10:52 AM, Andres Freund
> 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 yo
Tom,
* Tom Lane (t...@sss.pgh.pa.us) wrote:
> Stephen Frost writes:
> > Agreed- additional input from others would be great.
>
> I think this entire concept is a bad idea that will be a never-ending
> source of security holes. There are too many things that a user with
> filesystem access can d
On Wed, Oct 29, 2014 at 10:52 AM, Andres Freund 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 peopl
On 2014-10-29 10:47:58 -0400, Tom Lane wrote:
> Here is one trivial example: you want to let user joe import COPY
> data quickly, so you give him read access in directory foo, which he
> has write access on from his own account. Surely that's right in the
> middle of use cases you had in mind, or
Stephen Frost writes:
> Agreed- additional input from others would be great.
I think this entire concept is a bad idea that will be a never-ending
source of security holes. There are too many things that a user with
filesystem access can do to get superuser-equivalent status.
Here is one trivia
Robert Haas wrote:
> To articular my own concerns perhaps a bit better, there are two major
> things I don't like about the whole DIRALIAS proposal. Number one,
> you're creating this SQL object whose name is not actually used for
> anything other than manipulating the alias you created. The use
* Robert Haas (robertmh...@gmail.com) wrote:
> On Wed, Oct 29, 2014 at 6:50 AM, Stephen Frost wrote:
> > This could work though. We could add an array to pg_authid which is a
> > complex type that combines the permission allowed with the directory
> > somehow. Feels like it might get a bit clums
On Wed, Oct 29, 2014 at 6:50 AM, Stephen Frost wrote:
> This could work though. We could add an array to pg_authid which is a
> complex type that combines the permission allowed with the directory
> somehow. Feels like it might get a bit clumsy though.
Sure, I'm just throwing things out to see
Robert,
* Robert Haas (robertmh...@gmail.com) wrote:
> On Tue, Oct 28, 2014 at 3:19 PM, Stephen Frost wrote:
> > I agree that this makes it feel awkward. Peter had an interesting
> > suggestion to make the dir aliases available as actual aliases for the
> > commands which they would be relevant
* Peter Eisentraut (pete...@gmx.net) wrote:
> On 10/27/14 7:36 PM, Stephen Frost wrote:
> > MySQL:
> > http://dev.mysql.com/doc/refman/5.1/en/privileges-provided.html#priv_file
> >
> > (note they provide a way to limit access also, via secure_file_priv)
>
> They have a single privilege to allow t
On 10/27/14 7:36 PM, Stephen Frost wrote:
> MySQL:
> http://dev.mysql.com/doc/refman/5.1/en/privileges-provided.html#priv_file
>
> (note they provide a way to limit access also, via secure_file_priv)
They have a single privilege to allow the user to read or write any
file. I think that feature c
On Tue, Oct 28, 2014 at 3:19 PM, Stephen Frost wrote:
>> To articular my own concerns perhaps a bit better, there are two major
>> things I don't like about the whole DIRALIAS proposal. Number one,
>> you're creating this SQL object whose name is not actually used for
>> anything other than manip
Stephen Frost wrote:
> the original ask was to be able to view logs as a DBA who isn't a
> superuser, and without having to have those views delayed or
> complex cron jobs running to set up access to them.
I had kinda forgotten it, but I had to set up a cron log rsync at
Wisconsin Courts. I und
Robert,
* Robert Haas (robertmh...@gmail.com) wrote:
> On Tue, Oct 28, 2014 at 11:16 AM, Stephen Frost wrote:
> > There are more capabilities that I've been considering longer-term but
> > wasn't sure if they should be independent or just lumped into the
> > simpler read/write category:
> >
> > r
Kevin,
Thanks.
* Kevin Grittner (kgri...@ymail.com) wrote:
> Stephen my correct me on this, but I seem to remember him saying
> that this was part of a general effort to avoid needing to use a
> superuser login for routine tasks that don't fit into the area of
> what a sysadmin would do. That se
Robert Haas wrote:
> I think it would help, on all accounts, to explain why in the world
> we're spending time on this in the first place. I have a sneaking
> suspicion this is 1 of N things we need to do to meet some US
> government security standard, and if something like that is the case,
> t
On Tue, Oct 28, 2014 at 11:16 AM, Stephen Frost wrote:
> There are more capabilities that I've been considering longer-term but
> wasn't sure if they should be independent or just lumped into the
> simpler read/write category:
>
> read (eg: importing log files, or importing from an NFS mount)
> wr
On Tue, Oct 28, 2014 at 11:33 AM, Adam Brightwell
wrote:
>> Given that no fewer than four people - all committers - have expressed
>> doubts about the design of this patch, I wonder why you're bothering
>> to post a new version.
>
> I understand and my intent was in no way to disregard those conce
Robert,
> Given that no fewer than four people - all committers - have expressed
> doubts about the design of this patch, I wonder why you're bothering
> to post a new version.
I understand and my intent was in no way to disregard those concerns. The
only reason that I have posted a new versio
* Robert Haas (robertmh...@gmail.com) wrote:
> On Tue, Oct 28, 2014 at 9:24 AM, Stephen Frost wrote:
> > That said, it sounds like the primary concern has been if we want this
> > feature at all and there hasn't been much discussion of the design
> > itself. Comments about the technical design wo
On Tue, Oct 28, 2014 at 9:24 AM, Stephen Frost wrote:
> That said, it sounds like the primary concern has been if we want this
> feature at all and there hasn't been much discussion of the design
> itself. Comments about the technical design would be great. I
> appreciate your thoughts about usi
* Andres Freund (and...@2ndquadrant.com) wrote:
> On 2014-10-28 09:24:18 -0400, Stephen Frost wrote:
> > There is no doubt that consensus on the desirability and design needs
> > to be reached before we can even consider committing it. I suspect
> > Adam posted it simply because he had identified
On 2014-10-28 09:24:18 -0400, Stephen Frost wrote:
> * Robert Haas (robertmh...@gmail.com) wrote:
> > There is absolutely NOT consensus on
> > this design or anything close to it.
>
> There is no doubt that consensus on the desirability and design needs
> to be reached before we can even consider
* Robert Haas (robertmh...@gmail.com) wrote:
> There is absolutely NOT consensus on
> this design or anything close to it.
There is no doubt that consensus on the desirability and design needs
to be reached before we can even consider committing it. I suspect
Adam posted it simply because he had
On Mon, Oct 27, 2014 at 5:59 PM, Adam Brightwell
wrote:
> Attached is a patch with minor updates/corrections.
Given that no fewer than four people - all committers - have expressed
doubts about the design of this patch, I wonder why you're bothering
to post a new version. It seems to me that you
* Peter Eisentraut (pete...@gmx.net) wrote:
> I think the way this should work is that if you create a DIRALIAS, then
> the COPY command should refer to it by logical name, e.g.,
>
> CREATE DIRALIAS dumpster AS '/tmp/trash';
> COPY mytable TO dumpster;
You'd have to be able to specify the filenam
* Peter Eisentraut (pete...@gmx.net) wrote:
> On 10/27/14 7:27 AM, Stephen Frost wrote:
> > * Peter Eisentraut (pete...@gmx.net) wrote:
> >> On 10/16/14 12:01 PM, Stephen Frost wrote:
> >>> This started out as a request for a non-superuser to be able to review
> >>> the log files without needing ac
On 10/27/14 7:27 AM, Stephen Frost wrote:
> * Peter Eisentraut (pete...@gmx.net) wrote:
>> On 10/16/14 12:01 PM, Stephen Frost wrote:
>>> This started out as a request for a non-superuser to be able to review
>>> the log files without needing access to the server.
>>
>> I think that can be done wit
I think the way this should work is that if you create a DIRALIAS, then
the COPY command should refer to it by logical name, e.g.,
CREATE DIRALIAS dumpster AS '/tmp/trash';
COPY mytable TO dumpster;
If you squint a bit, this is the same as a tablespace. Maybe those two
concepts could be combine
All,
Attached is a patch with minor updates/corrections.
-Adam
--
Adam Brightwell - adam.brightw...@crunchydatasolutions.com
Database Engineer - www.crunchydatasolutions.com
diff --git a/src/backend/catalog/Makefile b/src/backend/catalog/Makefile
new file mode 100644
index b257b02..8cdc5cb
***
* Peter Eisentraut (pete...@gmx.net) wrote:
> On 10/16/14 12:01 PM, Stephen Frost wrote:
> > This started out as a request for a non-superuser to be able to review
> > the log files without needing access to the server.
>
> I think that can be done with a security-definer function.
Of course it c
Peter,
You patch is missing the files src/include/catalog/pg_diralias.h,
> src/include/commands/diralias.h, and src/backend/commands/diralias.c.
>
> (Hint: git add -N)
>
Yikes, sorry about that, not sure how that happened. Attached is an
updated patch.
-Adam
--
Adam Brightwell - adam.brightw.
You patch is missing the files src/include/catalog/pg_diralias.h,
src/include/commands/diralias.h, and src/backend/commands/diralias.c.
(Hint: git add -N)
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailp
On 10/16/14 12:01 PM, Stephen Frost wrote:
> This started out as a request for a non-superuser to be able to review
> the log files without needing access to the server.
I think that can be done with a security-definer function.
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.
* Bruce Momjian (br...@momjian.us) wrote:
> On Thu, Oct 16, 2014 at 12:01:28PM -0400, Stephen Frost wrote:
> > This started out as a request for a non-superuser to be able to review
> > the log files without needing access to the server. Now, things can
> > certainly be set up on the server to imp
On Thu, Oct 16, 2014 at 12:01:28PM -0400, Stephen Frost wrote:
> This started out as a request for a non-superuser to be able to review
> the log files without needing access to the server. Now, things can
> certainly be set up on the server to import *all* logs and then grant
> access to a non-su
* Robert Haas (robertmh...@gmail.com) wrote:
> On Wed, Oct 15, 2014 at 11:34 PM, Tom Lane wrote:
> > "Brightwell, Adam" writes:
> >> The attached patch for review implements a directory permission system that
> >> allows for providing a directory read/write capability to directories for
> >> COPY
On Wed, Oct 15, 2014 at 11:34 PM, Tom Lane wrote:
> "Brightwell, Adam" writes:
>> The attached patch for review implements a directory permission system that
>> allows for providing a directory read/write capability to directories for
>> COPY TO/FROM and Generic File Access Functions to non-super
"Brightwell, Adam" writes:
> The attached patch for review implements a directory permission system that
> allows for providing a directory read/write capability to directories for
> COPY TO/FROM and Generic File Access Functions to non-superusers.
TBH, this sounds like it's adding a lot of mecha
78 matches
Mail list logo
