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
On 2/26/15 1:00 AM, Fujii Masao wrote:
> On Thu, Feb 26, 2015 at 1:40 PM, Alvaro Herrera
>> Clearly if you log only DROP TABLE, and then the malicious user hides
>> one such call inside a function that executes the drop (which is called
>> via a SELECT top-level SQL), you're not going to be happy.
On 2/25/15 11:40 PM, Alvaro Herrera wrote:
> Fujii Masao wrote:
>> On Tue, Feb 24, 2015 at 1:29 AM, David Steele 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 loggin
On 2/25/15 10:42 PM, Fujii Masao wrote:
> On Tue, Feb 24, 2015 at 1:29 AM, David Steele 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 ove
On Thu, Feb 26, 2015 at 1:40 PM, Alvaro Herrera
wrote:
> Fujii Masao wrote:
>> On Tue, Feb 24, 2015 at 1:29 AM, David Steele 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
>> > greatl
Fujii Masao wrote:
> On Tue, Feb 24, 2015 at 1:29 AM, David Steele 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. It would
> >
On Tue, Feb 24, 2015 at 1:29 AM, David Steele 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 intentional?
>>
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
On 2/18/15 10:29 PM, Fujii Masao wrote:
> On Thu, Feb 19, 2015 at 12:25 AM, David Steele 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
On Thu, Feb 19, 2015 at 12:25 AM, David Steele wrote:
> 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 wrote:
>>> On 2/17/15 10:23 AM, Simon Riggs wrote:
I vote to include pgaud
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 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 h
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 sit
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 upda
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 wrote:
> > 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 r
Stephen,
I meant it to go to the list, but hit the wrong button.
> On Feb 17, 2015, at 7:01 PM, Stephen Frost 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 Tiffin (n
On Wed, Feb 18, 2015 at 1:26 AM, David Steele 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 (which isn't
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.
* 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 j
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 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'
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
st
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 t
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 na
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 ha
* 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 w
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 ver
Neil,
* Neil Tiffin (ne...@neiltiffin.com) wrote:
> > On Feb 17, 2015, at 3:40 AM, Yeb Havinga 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 cannot begin to i
* 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
> On Feb 17, 2015, at 3:40 AM, Yeb Havinga 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 of security
>
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 17 February 2015 at 15:52, Stephen Frost 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 code (which isn
* 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 p
On 17 February 2015 at 14:44, Stephen Frost 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 still at th
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.
>
> Reje
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-Sen wrote:
> So when I'm trying to decide what to audit, I have to:
>
> (a) check if the current user is menti
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-Sen 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
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
discussion continue. Perh
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 role
On Tue, Jan 27, 2015 at 6:54 PM, Jim Nasby wrote:
> On 1/27/15 5:06 PM, Robert Haas wrote:
>>
>> On Tue, Jan 27, 2015 at 5:55 PM, Jim Nasby
>> wrote:
>>>
>>> BTW, I know that at least earlier versions of EnterpriseDB's version of
>>> Postgres (circa 2007) had an auditing feature. I never dealt wi
On 1/27/15 5:06 PM, Robert Haas wrote:
On Tue, Jan 27, 2015 at 5:55 PM, Jim Nasby 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 o
On Tue, Jan 27, 2015 at 5:55 PM, Jim Nasby 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
> could shed some light o
On 1/26/15 4:45 PM, Robert Haas wrote:
On Mon, Jan 26, 2015 at 5:21 PM, Stephen Frost 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 par
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 Mon, Jan 26, 2015 at 5:21 PM, Stephen Frost 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
> certainly doesn't appe
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
> superus
Robert,
* Robert Haas (robertmh...@gmail.com) wrote:
> On Fri, Jan 23, 2015 at 1:16 PM, Stephen Frost 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 co
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
On Fri, Jan 23, 2015 at 1:16 PM, Stephen Frost 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 what's the ru
* 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 ma
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/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.
>
* Robert Haas (robertmh...@gmail.com) wrote:
> On Wed, Jan 21, 2015 at 7:05 PM, Jim Nasby 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 para
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
On Wed, Jan 21, 2015 at 1:42 AM, Abhijit Menon-Sen 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 approach that has
On Wed, Jan 21, 2015 at 7:05 PM, Jim Nasby 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 don't hear anyone who act
* 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 t
On 1/21/15 5:38 PM, Stephen Frost wrote:
* Jim Nasby (jim.na...@bluetreble.com) wrote:
On 1/20/15 9:01 PM, Stephen Frost wrote:
* 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
* Jim Nasby (jim.na...@bluetreble.com) wrote:
> On 1/20/15 9:01 PM, Stephen Frost wrote:
> >* 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
> >>>audi
On 1/20/15 9:01 PM, Stephen Frost wrote:
* 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
* 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.
>
[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 unders
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 wor
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
* Robert Haas (robertmh...@gmail.com) wrote:
> On Tue, Jan 20, 2015 at 1:05 AM, Abhijit Menon-Sen
> 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 desc
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 t
On Tue, Jan 20, 2015 at 5:03 PM, Jim Nasby 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 the
On 1/20/15 2:20 PM, Robert Haas wrote:
On Tue, Jan 20, 2015 at 1:05 AM, Abhijit Menon-Sen 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 th
On Tue, Jan 20, 2015 at 1:05 AM, Abhijit Menon-Sen 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
> mentioned in .roles; if
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 considere
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 consi
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
> ExecutorCheckPerms_
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 means
* Simon Riggs (si...@2ndquadrant.com) wrote:
> On 27 December 2014 at 08:47, Abhijit Menon-Sen 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 au
On 27 December 2014 at 08:47, Abhijit Menon-Sen 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 improves that considerab
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 25 December 2014 at 10:42, Abhijit Menon-Sen 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 not fully realis
On 25 December 2014 at 17:09, Jaime Casanova wrote:
> On Thu, Dec 25, 2014 at 5:42 AM, Abhijit Menon-Sen
> 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
On Thu, Dec 25, 2014 at 5:42 AM, Abhijit Menon-Sen 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 user).
what
At 2014-12-22 08:05:57 -0500, robertmh...@gmail.com wrote:
>
> On Tue, Dec 16, 2014 at 1:28 PM, Stephen Frost 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 effectively grant
On Tue, Dec 16, 2014 at 1:28 PM, Stephen Frost 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 permission
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
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 permiss
On 16 December 2014 at 21:45, Stephen Frost wrote:
> * Simon Riggs (si...@2ndquadrant.com) wrote:
>> On 16 December 2014 at 18:28, Stephen Frost 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 sho
* Simon Riggs (si...@2ndquadrant.com) wrote:
> On 16 December 2014 at 18:28, Stephen Frost 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
On 16 December 2014 at 18:28, Stephen Frost 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 http
* 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 w
On Fri, Oct 17, 2014 at 7:44 AM, Simon Riggs wrote:
> Thanks for the review.
>
> On 16 October 2014 23:23, MauMau 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'
Abhijit Menon-Sen 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 code.
> In the atta
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. Adds
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
On 14 October 2014 20:33, Abhijit Menon-Sen 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 than "ALTER
On 18 October 2014 05:13, MauMau 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 process does no
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 individ
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 sta
Thanks for the review.
On 16 October 2014 23:23, MauMau 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 afraid audit-lo
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 featu
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 t
* Simon Riggs (si...@2ndquadrant.com) wrote:
> On 14 October 2014 13:57, Stephen Frost 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
>
1 - 100 of 194 matches
Mail list logo
