On Thu, Feb 19, 2015 at 12:29:18PM +0900, Fujii Masao wrote:
The pg_audit doesn't log BIND parameter values when prepared statement is
used.
Seems this is an oversight of the patch. Or is this intentional?
It's actually intentional - following the model I talked about in my
earlier
On 2/25/15 11:40 PM, Alvaro Herrera wrote:
Fujii Masao wrote:
On Tue, Feb 24, 2015 at 1:29 AM, David Steele da...@pgmasters.net wrote:
1) Follow Oracle's as session option and only log each statement type
against an object the first time it happens in a session. This would
greatly reduce
On 2/25/15 10:42 PM, Fujii Masao wrote:
On Tue, Feb 24, 2015 at 1:29 AM, David Steele da...@pgmasters.net wrote:
On 2/18/15 10:25 AM, David Steele wrote:
On 2/18/15 6:11 AM, Fujii Masao wrote:
The pg_audit doesn't log BIND parameter values when prepared statement is
used.
Seems this is an
On Tue, Feb 24, 2015 at 1:29 AM, David Steele da...@pgmasters.net wrote:
On 2/18/15 10:25 AM, David Steele wrote:
On 2/18/15 6:11 AM, Fujii Masao wrote:
The pg_audit doesn't log BIND parameter values when prepared statement is
used.
Seems this is an oversight of the patch. Or is this
Fujii Masao wrote:
On Tue, Feb 24, 2015 at 1:29 AM, David Steele da...@pgmasters.net wrote:
1) Follow Oracle's as session option and only log each statement type
against an object the first time it happens in a session. This would
greatly reduce logging, but might be too little detail.
On Thu, Feb 26, 2015 at 1:40 PM, Alvaro Herrera
alvhe...@2ndquadrant.com wrote:
Fujii Masao wrote:
On Tue, Feb 24, 2015 at 1:29 AM, David Steele da...@pgmasters.net wrote:
1) Follow Oracle's as session option and only log each statement type
against an object the first time it happens in a
On 2/18/15 10:25 AM, David Steele wrote:
On 2/18/15 6:11 AM, Fujii Masao wrote:
The pg_audit doesn't log BIND parameter values when prepared statement is
used.
Seems this is an oversight of the patch. Or is this intentional?
It's actually intentional - following the model I talked about in
On 2/18/15 10:29 PM, Fujii Masao wrote:
On Thu, Feb 19, 2015 at 12:25 AM, David Steele da...@pgmasters.net wrote:
The pg_audit doesn't log BIND parameter values when prepared statement is
used.
Seems this is an oversight of the patch. Or is this intentional?
It's actually intentional -
On Wed, Feb 18, 2015 at 1:26 AM, David Steele da...@pgmasters.net wrote:
On 2/17/15 10:23 AM, Simon Riggs wrote:
I vote to include pgaudit in 9.5, albeit with any changes. In
particular, David may have some changes to recommend, but I haven't
seen a spec or a patch, just a new version of code
Stephen,
I meant it to go to the list, but hit the wrong button.
On Feb 17, 2015, at 7:01 PM, Stephen Frost sfr...@snowman.net wrote:
Neil,
I noticed that you email'd me directly on this reply. Not sure if you
intended to or not, but I'm fine with my response going to the list.
*
Neil,
* Neil Tiffin (ne...@neiltiffin.com) wrote:
I meant it to go to the list, but hit the wrong button.
No problem.
On Feb 17, 2015, at 7:01 PM, Stephen Frost sfr...@snowman.net wrote:
I noticed that you email'd me directly on this reply. Not sure if you
intended to or not, but I'm
Stephen Frost wrote:
Abhijit,
* Abhijit Menon-Sen (a...@2ndquadrant.com) wrote:
I'm confused and unhappy about your characterisation of the state of
this patch. You make it seem as though there was broad consensus about
the changes that were needed, and that I left the patch sitting in
Abhijit,
* Abhijit Menon-Sen (a...@2ndquadrant.com) wrote:
At 2015-02-17 13:01:46 -0500, sfr...@snowman.net wrote:
I have to admit that I'm confused by this. Patches don't stabilise
through sitting in the archives, they stabilise when the comments are
being addressed, the patch updated,
Hi Fujii,
Thanks for taking a look at the patch. Comments below:
On 2/18/15 6:11 AM, Fujii Masao wrote:
On Wed, Feb 18, 2015 at 1:26 AM, David Steele da...@pgmasters.net wrote:
On 2/17/15 10:23 AM, Simon Riggs wrote:
I vote to include pgaudit in 9.5, albeit with any changes. In
particular,
On 2/17/15 1:10 PM, Stephen Frost wrote:
What I'd prefer to see is a way to decouple the OS account from any
DB account. Clearly that doesn't protect us from the OS user doing
something bad, but at least then there's no way for them to just
silently run SQL commands.
If the DB account isn't a
* Jim Nasby (jim.na...@bluetreble.com) wrote:
On 2/17/15 1:10 PM, Stephen Frost wrote:
What I'd prefer to see is a way to decouple the OS account from any
DB account. Clearly that doesn't protect us from the OS user doing
something bad, but at least then there's no way for them to just
At 2015-02-17 13:01:46 -0500, sfr...@snowman.net wrote:
I have to admit that I'm confused by this. Patches don't stabilise
through sitting in the archives, they stabilise when the comments are
being addressed, the patch updated, and further comments are
addressing less important issues. The
At 2015-02-17 10:52:55 -0500, sfr...@snowman.net wrote:
From the old thread, David had offered to submit a pull request if
there was interest and I didn't see any response...
For whatever it's worth, that's because I've been away from work, and
only just returned. I had it on my list to look
On Feb 17, 2015, at 3:40 AM, Yeb Havinga yebhavi...@gmail.com wrote:
Hi list,
. . . . .
Auditing superuser access means auditing beyond the running database.
The superuser can dump a table, and pipe this data everywhere outside of
the auditing domain. I cannot begin to imagine the kind
On 17 February 2015 at 15:52, Stephen Frost sfr...@snowman.net wrote:
* Simon Riggs (si...@2ndquadrant.com) wrote:
I vote to include pgaudit in 9.5, albeit with any changes. In
particular, David may have some changes to recommend, but I haven't
seen a spec or a patch, just a new version of
* Simon Riggs (si...@2ndquadrant.com) wrote:
I vote to include pgaudit in 9.5, albeit with any changes. In
particular, David may have some changes to recommend, but I haven't
seen a spec or a patch, just a new version of code (which isn't how we
do things...).
Hrm. I thought David's new
Yeb,
* Yeb Havinga (yebhavi...@gmail.com) wrote:
On 20/01/15 23:03, Jim Nasby wrote: On 1/20/15 2:20 PM, Robert Haas wrote:
+1. In particular I'm very concerned with the idea of doing this via
roles, because that would make it trivial for any superuser to disable
auditing.
Rejecting the
On 2/17/15 4:40 AM, Yeb Havinga wrote:
On 20/01/15 23:03, Jim Nasby wrote: On 1/20/15 2:20 PM, Robert Haas wrote:
On Tue, Jan 20, 2015 at 1:05 AM, Abhijit
Menon-Sena...@2ndquadrant.com wrote:
So when I'm trying to decide what to audit, I have to:
(a) check if the current user is
On 17 February 2015 at 14:44, Stephen Frost sfr...@snowman.net wrote:
The patch as it is, is targeted at auditing user/application level
access to the database, and as such it matches the use case of auditing
user actions.
Right, and that's a *very* worthwhile use-case.
Agreed.
So, we are
On 2/17/15 12:07 PM, Stephen Frost wrote:
My views are from working with FDA validated environments, and I don’t really
understand the above. It is not db auditing’s job to stop or control the
access to data or to log what happens to data outside of PostgreSQL. To audit
a db superuser is
On 2/17/15 12:23 PM, Stephen Frost wrote:
* Jim Nasby (jim.na...@bluetreble.com) wrote:
On 2/17/15 12:07 PM, Stephen Frost wrote:
I agree that it's not the auditing job to stop or control access to
data, but it's not so simple to audit the superuser completely. The
issue is that even if you
* Simon Riggs (si...@2ndquadrant.com) wrote:
David's work is potentially useful, but having two versions of a
feature slows things down. Since he is new to development here, I have
made those comments so he understands, not so you would pick up on
that.
I have a bad tendency of replying to
* Jim Nasby (jim.na...@bluetreble.com) wrote:
On 2/17/15 12:07 PM, Stephen Frost wrote:
I agree that it's not the auditing job to stop or control access to
data, but it's not so simple to audit the superuser completely. The
issue is that even if you have a hard-coded bit in the binary which
Jim,
* Jim Nasby (jim.na...@bluetreble.com) wrote:
We may need to bite the bullet and allow changing the user that the
postgres process runs under so it doesn't match who owns the files.
Maybe there's a way to allow that other than having the process
start as root.
That's an interesting
On 2/17/15 12:50 PM, Stephen Frost wrote:
Jim,
* Jim Nasby (jim.na...@bluetreble.com) wrote:
We may need to bite the bullet and allow changing the user that the
postgres process runs under so it doesn't match who owns the files.
Maybe there's a way to allow that other than having the process
* Jim Nasby (jim.na...@bluetreble.com) wrote:
On 2/17/15 12:50 PM, Stephen Frost wrote:
* Jim Nasby (jim.na...@bluetreble.com) wrote:
We may need to bite the bullet and allow changing the user that the
postgres process runs under so it doesn't match who owns the files.
Maybe there's a way to
Neil,
* Neil Tiffin (ne...@neiltiffin.com) wrote:
On Feb 17, 2015, at 3:40 AM, Yeb Havinga yebhavi...@gmail.com wrote:
Auditing superuser access means auditing beyond the running database.
The superuser can dump a table, and pipe this data everywhere outside of
the auditing domain. I
On 2/17/15 10:23 AM, Simon Riggs wrote:
I vote to include pgaudit in 9.5, albeit with any changes. In
particular, David may have some changes to recommend, but I haven't
seen a spec or a patch, just a new version of code (which isn't how we
do things...).
I submitted the new patch in my name
Hi list,
On 20/01/15 23:03, Jim Nasby wrote: On 1/20/15 2:20 PM, Robert Haas wrote:
On Tue, Jan 20, 2015 at 1:05 AM, Abhijit
Menon-Sena...@2ndquadrant.com wrote:
So when I'm trying to decide what to audit, I have to:
(a) check if the current user is mentioned in .roles; if so,
audit.
On Tue, Jan 27, 2015 at 6:08 PM, Abhijit Menon-Sen a...@2ndquadrant.com
wrote:
Anyway, I think it's reasonably clear now that pgaudit is unlikely to
make it into 9.5 in any form, so I'll find something else to do.
Well, I am marking this patch as rejected then... Let's in any case the
On 2/2/15 3:49 PM, David Steele wrote:
The role-base approach being considered may strike some as a misuse of
the role system, but to my eye it is syntactically very close to how
Oracle does auditing prior to 12c. Say you wanted to audit selects on
the table hr.employee:
Oracle: AUDIT
On 1/27/15 4:08 AM, Abhijit Menon-Sen wrote:
Anyway, I think it's reasonably clear now that pgaudit is unlikely to
make it into 9.5 in any form, so I'll find something else to do.
That's unfortunate. I've been following this thread for a while with
some interest (and anticipation).
The
At 2015-01-26 17:45:52 -0500, robertmh...@gmail.com wrote:
Based on the recent emails, it appears there's been a shift of
preference to having it be in-core […]
Well, I'm not sure that anyone else here agreed with me on that
Sure, an in-core AUDIT command would be great. Stephen has
On Tue, Jan 27, 2015 at 5:55 PM, Jim Nasby jim.na...@bluetreble.com wrote:
BTW, I know that at least earlier versions of EnterpriseDB's version of
Postgres (circa 2007) had an auditing feature. I never dealt with any
customers who were using it when I was there, but perhaps some other folks
On Tue, Jan 27, 2015 at 6:54 PM, Jim Nasby jim.na...@bluetreble.com wrote:
On 1/27/15 5:06 PM, Robert Haas wrote:
On Tue, Jan 27, 2015 at 5:55 PM, Jim Nasby jim.na...@bluetreble.com
wrote:
BTW, I know that at least earlier versions of EnterpriseDB's version of
Postgres (circa 2007) had an
On 1/26/15 4:45 PM, Robert Haas wrote:
On Mon, Jan 26, 2015 at 5:21 PM, Stephen Frost sfr...@snowman.net wrote:
I don't disagree with you about any of that. I don't think you disagree
with my comment either. What I'm not entirely clear on is how consensus
could be reached. Leaving it dormant
On 1/27/15 5:06 PM, Robert Haas wrote:
On Tue, Jan 27, 2015 at 5:55 PM, Jim Nasby jim.na...@bluetreble.com wrote:
BTW, I know that at least earlier versions of EnterpriseDB's version of
Postgres (circa 2007) had an auditing feature. I never dealt with any
customers who were using it when I was
On 1/23/15 2:15 PM, Stephen Frost wrote:
I happen to like the idea specifically because it would allow regular
roles to change the auditing settings (no need to be a superuser or to
be able to modify postgresql.conf/postgresql.auto.conf)
Is there really a use case for non-superusers to be
On Fri, Jan 23, 2015 at 1:16 PM, Stephen Frost sfr...@snowman.net wrote:
Well, I'm still of the view that there's little to lose by having this
remain out-of-core for a release or three. We don't really all agree
on what we want, and non-core code can evolve a lot faster than core
code, so
On Mon, Jan 26, 2015 at 5:21 PM, Stephen Frost sfr...@snowman.net wrote:
I don't disagree with you about any of that. I don't think you disagree
with my comment either. What I'm not entirely clear on is how consensus
could be reached. Leaving it dormant for the better part of a year
Robert,
* Robert Haas (robertmh...@gmail.com) wrote:
On Fri, Jan 23, 2015 at 1:16 PM, Stephen Frost sfr...@snowman.net wrote:
Well, I'm still of the view that there's little to lose by having this
remain out-of-core for a release or three. We don't really all agree
on what we want, and
Jim,
* Jim Nasby (jim.na...@bluetreble.com) wrote:
When it comes to changing auditing settings, I think that needs to be very
restrictive. Really, it should be more (or differently) restrictive than SU,
so that you can effectively audit your superusers with minimal worries about
superusers
On Wed, Jan 21, 2015 at 1:42 AM, Abhijit Menon-Sen a...@2ndquadrant.com wrote:
At 2015-01-20 20:36:39 -0500, robertmh...@gmail.com wrote:
I think this is throwing the baby out with the bathwater. Neither C
functions nor all-or-nothing are going to be of any practical use.
Do you see some
On Wed, Jan 21, 2015 at 7:05 PM, Jim Nasby jim.na...@bluetreble.com wrote:
I'm still nervous about overloading this onto the roles system; I think it
will end up being very easy to accidentally break. But if others think it'll
work then I guess I'm just being paranoid.
I agree with you. I
* Robert Haas (robertmh...@gmail.com) wrote:
On Wed, Jan 21, 2015 at 7:05 PM, Jim Nasby jim.na...@bluetreble.com wrote:
I'm still nervous about overloading this onto the roles system; I think it
will end up being very easy to accidentally break. But if others think it'll
work then I guess
On 1/21/15 6:50 PM, Stephen Frost wrote:
I'm still nervous about overloading this onto the roles system; I think it will
end up being very easy to accidentally break. But if others think it'll work
then I guess I'm just being paranoid.
Break in which way..? If you're saying it'll be easy for
* Jim Nasby (jim.na...@bluetreble.com) wrote:
On 1/21/15 6:50 PM, Stephen Frost wrote:
I'm still nervous about overloading this onto the roles system; I think it
will end up being very easy to accidentally break. But if others think
it'll work then I guess I'm just being paranoid.
Break in
On 1/23/15 12:16 PM, Stephen Frost wrote:
Just to clarify- this concept isn't actually mine but was suggested by a
pretty sizable PG user who has a great deal of familiarity with other
databases. I don't mean to try and invoke the 'silent majority' but
rather to make sure folks don't think this
* Jim Nasby (jim.na...@bluetreble.com) wrote:
On 1/23/15 12:16 PM, Stephen Frost wrote:
Just to clarify- this concept isn't actually mine but was suggested by a
pretty sizable PG user who has a great deal of familiarity with other
databases. I don't mean to try and invoke the 'silent
* Jim Nasby (jim.na...@bluetreble.com) wrote:
On 1/21/15 5:38 PM, Stephen Frost wrote:
Being startup-only won't help if the user is a superuser.
Crap, I thought postgresql.auto.conf was handled as an #include and therefore
you could still preempt it via postgresql.conf
It's not just that..
[After a discussion on IRC with Stephen…]
At 2015-01-20 21:47:02 -0500, sfr...@snowman.net wrote:
Review the opening of this email though and consider that we could
look at what privileges has the audit role granted to the current
role? as defining what is to be audited.
Right, I understand
* Abhijit Menon-Sen (a...@2ndquadrant.com) wrote:
At 2015-01-20 21:47:02 -0500, sfr...@snowman.net wrote:
Review the opening of this email though and consider that we could
look at what privileges has the audit role granted to the current
role? as defining what is to be audited.
Right, I
On Tue, Jan 20, 2015 at 1:05 AM, Abhijit Menon-Sen a...@2ndquadrant.com wrote:
So when I'm trying to decide what to audit, I have to:
(a) check if the current user is mentioned in .roles; if so, audit.
(b) check if the current user is a descendant of one of the roles
* Robert Haas (robertmh...@gmail.com) wrote:
On Tue, Jan 20, 2015 at 1:05 AM, Abhijit Menon-Sen a...@2ndquadrant.com
wrote:
So when I'm trying to decide what to audit, I have to:
(a) check if the current user is mentioned in .roles; if so, audit.
(b) check if the current user
On Tue, Jan 20, 2015 at 5:03 PM, Jim Nasby jim.na...@bluetreble.com wrote:
+1. In particular I'm very concerned with the idea of doing this via roles,
because that would make it trivial for any superuser to disable auditing.
The only good option I could see to provide this kind of flexibility
Abhijit,
* Abhijit Menon-Sen (a...@2ndquadrant.com) wrote:
At 2015-01-19 08:26:59 -0500, sfr...@snowman.net wrote:
I'm confused by this statement..
Let me see if I've understood your clarification:
Thanks much for the example use-case and for working this through with
me. I actually think
Jim,
* Jim Nasby (jim.na...@bluetreble.com) wrote:
+1. In particular I'm very concerned with the idea of doing this via roles,
because that would make it trivial for any superuser to disable auditing. The
only good option I could see to provide this kind of flexibility would be
allowing
On 1/20/15 2:20 PM, Robert Haas wrote:
On Tue, Jan 20, 2015 at 1:05 AM, Abhijit Menon-Sena...@2ndquadrant.com wrote:
So when I'm trying to decide what to audit, I have to:
(a) check if the current user is mentioned in .roles; if so, audit.
(b) check if the current user is a
At 2015-01-20 20:36:39 -0500, robertmh...@gmail.com wrote:
I think this is throwing the baby out with the bathwater. Neither C
functions nor all-or-nothing are going to be of any practical use.
Do you see some approach that has a realistic chance of making 9.5 and
would also actually be worth
At 2015-01-19 08:26:59 -0500, sfr...@snowman.net wrote:
I'm confused by this statement..
Let me see if I've understood your clarification:
Suppose you have pgaudit.roles set to 'r0, r1', and that you have
granted r0 to u0.
Now, if you're connected to the database as r0 or r1, then everything
Abhijit,
* Abhijit Menon-Sen (a...@2ndquadrant.com) wrote:
At 2015-01-18 22:28:37 -0500, sfr...@snowman.net wrote:
2. Set pgaudit.roles = 'r1, r2, …', which logs everything done by r1,
r2, and any of their descendants.
If these roles were the 'audit' roles as considered under #1
Abhijit,
Apologies, I've been meaning to go through this for quite some time.
* Abhijit Menon-Sen (a...@2ndquadrant.com) wrote:
I've changed pgaudit to work as you suggested.
Great, glad to see that.
A quick note on the implementation: pgaudit was already installing an
Hello Stephen.
Thanks very much for having a look at the revised pgaudit.
At 2015-01-18 22:28:37 -0500, sfr...@snowman.net wrote:
2. Set pgaudit.roles = 'r1, r2, …', which logs everything done by r1,
r2, and any of their descendants.
If these roles were the 'audit' roles as considered
Hi.
I've changed pgaudit to work as you suggested.
A quick note on the implementation: pgaudit was already installing an
ExecutorCheckPerms_hook anyway; I adapted code from ExecRTECheckPerms
to check if the audit role has been granted any of the permissions
required for the operation.
This
On 25 December 2014 at 17:09, Jaime Casanova ja...@2ndquadrant.com wrote:
On Thu, Dec 25, 2014 at 5:42 AM, Abhijit Menon-Sen a...@2ndquadrant.com
wrote:
To summarise for people who haven't followed the thread in detail, the
idea is that you would do:
grant select on foo to audit;
On 25 December 2014 at 10:42, Abhijit Menon-Sen a...@2ndquadrant.com wrote:
Stephen likes the idea, obviously; Simon also said he liked it, but I
now wonder if he may have liked the part I implemented (which allows a
hot standby to have a different auditing configuration than the primary)
but
At 2014-12-27 08:08:32 +, si...@2ndquadrant.com wrote:
what if i want to audit different things for different users?
That is supported - you can provide a list of roles to be audit roles.
You can do that, but maybe it isn't quite enough to do what Jaime is
asking for. Not always, at
On 27 December 2014 at 08:47, Abhijit Menon-Sen a...@2ndquadrant.com wrote:
But there's no way to say *don't* audit select on foo by simon.
We can cover what it does and does not do in some doc examples.
When submitted, pgaudit didn't have very complex auditing rules.
Stephen's suggestion
* Simon Riggs (si...@2ndquadrant.com) wrote:
On 27 December 2014 at 08:47, Abhijit Menon-Sen a...@2ndquadrant.com wrote:
But there's no way to say *don't* audit select on foo by simon.
We can cover what it does and does not do in some doc examples.
When submitted, pgaudit didn't have
At 2014-12-22 08:05:57 -0500, robertmh...@gmail.com wrote:
On Tue, Dec 16, 2014 at 1:28 PM, Stephen Frost sfr...@snowman.net wrote:
… ok, does the audit role have any permissions here? and, if the
result is yes, then the command is audited. …
This is a little weird because you're
On Thu, Dec 25, 2014 at 5:42 AM, Abhijit Menon-Sen a...@2ndquadrant.com wrote:
To summarise for people who haven't followed the thread in detail, the
idea is that you would do:
grant select on foo to audit;
...and the server would audit-log any select ... from foo ... queries (by
any
On Tue, Dec 16, 2014 at 1:28 PM, Stephen Frost sfr...@snowman.net wrote:
The magic audit role has SELECT rights on a given table. When any
user does a SELECT against that table, ExecCheckRTPerms is called and
there's a hook there which the module can use to say ok, does the audit
role have
At 2014-12-16 13:28:07 -0500, sfr...@snowman.net wrote:
The magic audit role has SELECT rights on a given table. When any
user does a SELECT against that table, ExecCheckRTPerms is called and
there's a hook there which the module can use to say ok, does the
audit role have any permissions
Abhijit,
* Abhijit Menon-Sen (a...@2ndquadrant.com) wrote:
At 2014-12-16 13:28:07 -0500, sfr...@snowman.net wrote:
The magic audit role has SELECT rights on a given table. When any
user does a SELECT against that table, ExecCheckRTPerms is called and
there's a hook there which the
On 16 December 2014 at 21:45, Stephen Frost sfr...@snowman.net wrote:
* Simon Riggs (si...@2ndquadrant.com) wrote:
On 16 December 2014 at 18:28, Stephen Frost sfr...@snowman.net wrote:
For the sake of the archives, the idea I had been trying to propose is
to use a role's permissions as a
* Michael Paquier (michael.paqu...@gmail.com) wrote:
Do you have real numbers about the performance impact that this module
has when plugged in the server? If yes, it would be good to get an
idea of how much audit costs and if it has a clear performance impact
this should be documented to warn
On 16 December 2014 at 18:28, Stephen Frost sfr...@snowman.net wrote:
For the sake of the archives, the idea I had been trying to propose is
to use a role's permissions as a mechanism to define what should be
audited. An example is:
My understanding is that was done.
--
Simon Riggs
* Simon Riggs (si...@2ndquadrant.com) wrote:
On 16 December 2014 at 18:28, Stephen Frost sfr...@snowman.net wrote:
For the sake of the archives, the idea I had been trying to propose is
to use a role's permissions as a mechanism to define what should be
audited. An example is:
My
On 14 October 2014 20:33, Abhijit Menon-Sen a...@2ndquadrant.com wrote:
At 2014-10-14 20:09:50 +0100, si...@2ndquadrant.com wrote:
I think that's a good idea.
We could have pg_audit.roles = 'audit1, audit2'
Yes, it's a neat idea, and we could certainly do that. But why is it any
better
At 2014-11-03 17:31:37 +, si...@2ndquadrant.com wrote:
Stephen's suggestion allows auditing to be conducted without the
users/apps being aware it is taking place.
OK, that makes sense. I'm working on a revised patch that does things
this way, and will post it in a few days.
-- Abhijit
Hi.
I could actually use some comments on the approach. I've attached
a prototype I've been working on (which is a cut down version of
my earlier code; but it's not terribly interesting and you don't
need to read it to comment on my questions below). The attached
patch does the following:
1.
Abhijit Menon-Sen a...@2ndquadrant.com writes:
Earlier, I was using a combination of check and assign hooks to convert
names to OIDs, but (as Andres pointed out) that would have problems with
cache invalidations. I was even playing with caching membership lookups,
but I ripped out all that
On 18/10/14 06:13, MauMau wrote:
[requirement]
10.2.3 Verify access to all audit trails is logged.
Malicious users often attempt to alter audit logs to
hide their actions, and a record of access allows
an organization to trace any inconsistencies or
potential tampering of the logs to an
On 18 October 2014 05:13, MauMau maumau...@gmail.com wrote:
[requirement]
10.6 Review logs and security events for
all system components to identify
anomalies or suspicious activity.
Note: Log harvesting, parsing, and
alerting tools may be used to meet this
Requirement.
The log review
Hello,
As I said in the previous mail, I looked into the latest PCI DSS 3.0 to find
out whether and how pgaudit fulfills the requirements related to auditing.
I believe that even the initial version of pgaudit needs to have enough
functionalities to meet the requirements of some well-known
Hello,
I had a quick look through the code and did some testing. Let me give you
some comments. I will proceed with checking if pgaudit can meet PCI DSS
requirements.
By the way, I'd like to use pgaudit with 9.2. Is it possible with a slight
modification of the code? If it is, what
Thanks for the review.
On 16 October 2014 23:23, MauMau maumau...@gmail.com wrote:
(3)
SELECT against a view generated two audit log lines, one for the view
itself, and the other for the underlying table. Is this intended? I'm not
saying that's wrong but just asking.
Intended
(4)
I'm
Hi.
As before, the pgaudit code is at https://github.com/2ndQuadrant/pgaudit
I did a quick round of testing to make sure things still work.
I'll re-add it to the next CF now.
-- Abhijit
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your
At 2014-10-14 18:05:00 +0530, a...@2ndquadrant.com wrote:
As before, the pgaudit code is at
https://github.com/2ndQuadrant/pgaudit
Sorry, I forgot to attach the tarball.
-- Abhijit
pgaudit.tar.gz
Description: Binary data
--
Sent via pgsql-hackers mailing list
Abhijit,
* Abhijit Menon-Sen (a...@2ndquadrant.com) wrote:
As before, the pgaudit code is at https://github.com/2ndQuadrant/pgaudit
I did a quick round of testing to make sure things still work.
Thanks!
I had a very interesting discussion about auditing rules and the need to
limit what gets
On 14 October 2014 13:57, Stephen Frost sfr...@snowman.net wrote:
Create an 'audit' role.
Every command run by roles which are granted to the 'audit' role are
audited.
Every 'select' against tables which the 'audit' role has 'select' rights
on are audited. Similairly for every insert,
* Simon Riggs (si...@2ndquadrant.com) wrote:
On 14 October 2014 13:57, Stephen Frost sfr...@snowman.net wrote:
Create an 'audit' role.
Every command run by roles which are granted to the 'audit' role are
audited.
Every 'select' against tables which the 'audit' role has 'select'
At 2014-10-14 20:09:50 +0100, si...@2ndquadrant.com wrote:
I think that's a good idea.
We could have pg_audit.roles = 'audit1, audit2'
Yes, it's a neat idea, and we could certainly do that. But why is it any
better than ALTER ROLE audit_rw SET pgaudit.log = … and granting that
role to the
From: Simon Riggs si...@2ndquadrant.com
I hope we can get pgAudit in as a module for 9.5. I also hope that it
will stimulate the requirements/funding of further work in this area,
rather than squash it. My feeling is we have more examples of feature
sets that grow over time (replication, view
* Fabrízio de Royes Mello (fabriziome...@gmail.com) wrote:
On Tue, Oct 7, 2014 at 1:24 PM, Simon Riggs si...@2ndquadrant.com wrote:
I hope we can get pgAudit in as a module for 9.5. I also hope that it
will stimulate the requirements/funding of further work in this area,
rather than squash
1 - 100 of 189 matches
Mail list logo
