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
* 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 the user to
Robert,
* Robert Haas (robertmh...@gmail.com) wrote:
On Tue, Oct 28, 2014 at 3:19 PM, Stephen Frost sfr...@snowman.net 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
On Wed, Oct 29, 2014 at 6:50 AM, Stephen Frost sfr...@snowman.net 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
* Robert Haas (robertmh...@gmail.com) wrote:
On Wed, Oct 29, 2014 at 6:50 AM, Stephen Frost sfr...@snowman.net 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
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 users
Stephen Frost sfr...@snowman.net 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.
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
On Wed, Oct 29, 2014 at 10:52 AM, Andres Freund and...@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
Tom,
* Tom Lane (t...@sss.pgh.pa.us) wrote:
Stephen Frost sfr...@snowman.net 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
* Robert Haas (robertmh...@gmail.com) wrote:
On Wed, Oct 29, 2014 at 10:52 AM, Andres Freund and...@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
Robert Haas wrote:
On Wed, Oct 29, 2014 at 10:52 AM, Andres Freund and...@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
* Alvaro Herrera (alvhe...@2ndquadrant.com) wrote:
Robert Haas wrote:
On Wed, Oct 29, 2014 at 10:52 AM, Andres Freund and...@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
Stephen Frost sfr...@snowman.net 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
On Wed, Oct 29, 2014 at 11:34 AM, Stephen Frost sfr...@snowman.net 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
On 2014-10-29 11:52:43 -0400, Robert Haas wrote:
On Wed, Oct 29, 2014 at 11:34 AM, Stephen Frost sfr...@snowman.net 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
On Wed, Oct 29, 2014 at 12:00 PM, Andres Freund and...@2ndquadrant.com 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
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 independent.
I
Stephen Frost sfr...@snowman.net 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.
* 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 cases
On 2014-10-29 12:09:00 -0400, Tom Lane wrote:
Stephen Frost sfr...@snowman.net 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
Stephen Frost sfr...@snowman.net 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
* Tom Lane (t...@sss.pgh.pa.us) wrote:
Stephen Frost sfr...@snowman.net 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
Stephen Frost sfr...@snowman.net 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
* 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
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
still
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 do
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
On Wed, Oct 29, 2014 at 12:36 PM, Adam Brightwell
adam.brightw...@crunchydatasolutions.com 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
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:
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.
* 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 to
Stephen Frost sfr...@snowman.net 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
Andres Freund and...@2ndquadrant.com 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
Tom Lane t...@sss.pgh.pa.us 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
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 (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
Stephen Frost sfr...@snowman.net 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
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
* 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
Stephen Frost sfr...@snowman.net 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
* Tom Lane (t...@sss.pgh.pa.us) wrote:
Stephen Frost sfr...@snowman.net 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
Stephen Frost sfr...@snowman.net 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
On Wed, Oct 29, 2014 at 3:31 PM, Stephen Frost sfr...@snowman.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
* Tom Lane (t...@sss.pgh.pa.us) wrote:
Stephen Frost sfr...@snowman.net 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
* Robert Haas (robertmh...@gmail.com) wrote:
On Wed, Oct 29, 2014 at 3:31 PM, Stephen Frost sfr...@snowman.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,
Tom Lane t...@sss.pgh.pa.us 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
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 on earth
On Mon, Oct 27, 2014 at 5:59 PM, Adam Brightwell
adam.brightw...@crunchydatasolutions.com 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
* 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 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
* 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 issues
On Tue, Oct 28, 2014 at 9:24 AM, Stephen Frost sfr...@snowman.net 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
* Robert Haas (robertmh...@gmail.com) wrote:
On Tue, Oct 28, 2014 at 9:24 AM, Stephen Frost sfr...@snowman.net 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
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 version
On Tue, Oct 28, 2014 at 11:33 AM, Adam Brightwell
adam.brightw...@crunchydatasolutions.com 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
On Tue, Oct 28, 2014 at 11:16 AM, Stephen Frost sfr...@snowman.net 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
Robert Haas robertmh...@gmail.com 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
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 seems
Robert,
* Robert Haas (robertmh...@gmail.com) wrote:
On Tue, Oct 28, 2014 at 11:16 AM, Stephen Frost sfr...@snowman.net 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
Stephen Frost sfr...@snowman.net 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
On Tue, Oct 28, 2014 at 3:19 PM, Stephen Frost sfr...@snowman.net 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
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
* 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 can be.
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
***
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
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 with a
* 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 access to the
* 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 filename
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
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:
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 -
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
* 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 import
On Wed, Oct 15, 2014 at 11:34 PM, Tom Lane t...@sss.pgh.pa.us wrote:
Brightwell, Adam adam.brightw...@crunchydatasolutions.com writes:
The attached patch for review implements a directory permission system that
allows for providing a directory read/write capability to directories for
COPY
* Robert Haas (robertmh...@gmail.com) wrote:
On Wed, Oct 15, 2014 at 11:34 PM, Tom Lane t...@sss.pgh.pa.us wrote:
Brightwell, Adam adam.brightw...@crunchydatasolutions.com writes:
The attached patch for review implements a directory permission system that
allows for providing a directory
All,
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. This is
not a complete solution as it does not currently contain
Brightwell, Adam adam.brightw...@crunchydatasolutions.com 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
78 matches
Mail list logo
