out of these features, and their dangerous side effects, but
treating mod_log_forensic as 'just a logging tool' is foolish.
On 08 Jun 2012, at 7:22 PM, Joe Schaefer wrote:
> For several years Graham those logs were rather valuable
> in tracking down segfaulting svn requests. Security releases
> were made as a result of some of those reports to the
>
> Subversion project.
I'm sure they were, that's exactly what the
On 6/8/2012 12:52 PM, Jim Riggs wrote:
> Having the forensic logs available has proven extremely helpful in this
> scenario. Might the full, unfiltered forensic data be valuable? Yes, but I
> don't believe the security risk is worth it in my situation. The rare case
> where an Authorization head
On Jun 8, 2012, at 11:51 AM, Graham Leggett wrote:
> On 08 Jun 2012, at 5:45 PM, Joe Schaefer wrote:
>
>> Well not quite, we'd still have had a problem with storing and archiving
>> those logs even if we hadn't made them available to committers, because
>> they violate our password retention poli
:
> Sent: Friday, June 8, 2012 12:51 PM
> Subject: Re: [PATCH] mod_log_forensic security considerations
>
> On 08 Jun 2012, at 5:45 PM, Joe Schaefer wrote:
>
>> Well not quite, we'd still have had a problem with storing and
> archiving
>> those logs even if we hadn&
On 08 Jun 2012, at 5:45 PM, Joe Schaefer wrote:
> Well not quite, we'd still have had a problem with storing and archiving
> those logs even if we hadn't made them available to committers, because
> they violate our password retention policies.
Can you clarify if possible what purpose you were tr
On 06/08/2012 05:45 PM, Joe Schaefer wrote:
> Well not quite, we'd still have had a problem with storing and
> archiving those logs even if we hadn't made them available to
> committers, because they violate our password retention policies.
My point was, that it should fall upon us to add a filter
- Original Message -
> From: Daniel Gruno
> To: dev@httpd.apache.org
> Cc:
> Sent: Friday, June 8, 2012 6:24 AM
> Subject: Re: [PATCH] mod_log_forensic security considerations
>
> On 06/08/2012 12:13 PM, Graham Leggett wrote:
>> On 08 Jun 2012, at 12:
that is needed.
>>
>> IMO, having unadulterated logging capability is what makes
>> mod_dumpio/mod_log_forensic some of the most useful modules for
>> troubleshooting in a proxy/crashing scenario (respectively).
> +1.
>
> Regards,
> Graham
> --
>
+1 to that. We
isn't enabled by default and is most likely
> to be enabled by a user that knows what they are trying to accomplish.
> To me, a clear and concise security warning in the documentation should
> be all that is needed.
>
> IMO, having unadulterated logging capability is what makes
>
> -Original Message-
> From: Daniel Ruggeri > Sent: Freitag, 8. Juni 2012 00:16
> To: dev@httpd.apache.org
> Subject: Re: [PATCH] mod_log_forensic security considerations
>
> On 6/7/2012 3:11 PM, Stefan Fritsch wrote:
> > On Thursday 07 June 2012, Eric Covene
27;t enabled by default and is most likely
to be enabled by a user that knows what they are trying to accomplish.
To me, a clear and concise security warning in the documentation should
be all that is needed.
IMO, having unadulterated logging capability is what makes
mod_dumpio/mod_log_forensic some of the most useful modules for
troubleshooting in a proxy/crashing scenario (respectively).
--
Daniel Ruggeri
On Jun 7, 2012, at 3:11 PM, Stefan Fritsch wrote:
> I share Williams concern that this makes mod_forensic potentially less
> useful.
>
> Maybe making the forensic log mode 600 by default would be a better
> idea?
I have to agree with Jeff. I would rather have a more difficult or even
impossi
On Thu, Jun 7, 2012 at 4:11 PM, Stefan Fritsch wrote:
> On Thursday 07 June 2012, Eric Covener wrote:
>> On Wed, Jun 6, 2012 at 9:15 PM, Jeff Trawick
> wrote:
>> > On Wed, Jun 6, 2012 at 3:49 PM, Joe Schaefer
> wrote:
>> >> Session cookies sometimes pose a security risk as well.
>> >
>> > Yeah.
On Thursday 07 June 2012, Eric Covener wrote:
> On Wed, Jun 6, 2012 at 9:15 PM, Jeff Trawick
wrote:
> > On Wed, Jun 6, 2012 at 3:49 PM, Joe Schaefer
wrote:
> >> Session cookies sometimes pose a security risk as well.
> >
> > Yeah. That could be any cookie though although there are a few
> > v
d be a useful feature to allow excluding those headers
>>>> from being logged, too.
>>>
>>> IMO they shouldn't be logged by default (if at all).
>>> Proxy-Authorization also needs to be handled. (Anything else? My
>>> search query foo is particularl
g logged, too.
>>
>> IMO they shouldn't be logged by default (if at all).
>> Proxy-Authorization also needs to be handled. (Anything else? My
>> search query foo is particularly bad today.)
>
> ANY parsing which occurs within mod_log_forensic is going to open th
On Wed, Jun 6, 2012 at 9:15 PM, Jeff Trawick wrote:
> On Wed, Jun 6, 2012 at 3:49 PM, Joe Schaefer wrote:
>> Session cookies sometimes pose a security risk as well.
>
> Yeah. That could be any cookie though although there are a few very
> common defaults :( My guess is that cookie values are mo
ers, but that it should still
be opt-in.
Thoughts, anyone?
>
>
>
> - Original Message -
>> From: Jeff Trawick
>> To: d...@httpd.apache.org; dev@httpd.apache.org
>> Cc:
>> Sent: Wednesday, June 6, 2012 3:46 PM
>> Subject: Re: [PATCH] mod_log_forensic
Session cookies sometimes pose a security risk as well.
- Original Message -
> From: Jeff Trawick
> To: d...@httpd.apache.org; dev@httpd.apache.org
> Cc:
> Sent: Wednesday, June 6, 2012 3:46 PM
> Subject: Re: [PATCH] mod_log_forensic security considerations
>
>
On Tue, May 29, 2012 at 1:36 PM, Daniel Shahaf wrote:
> https://blogs.apache.org/infra/entry/apache_org_incident_report_for
>
> Infra got bit by mod_log_forensic logs including Authorization headers
> and being world-readable, so in an effort to save someone else from
> repeating t
think I could add a small timestamp patch for
mod_log_forensic for future convenience.
regs,
Christian
--
Christian Folini -
On 30 Mar 2011, at 3:23 PM, Christian Folini wrote:
Mod_log_forensic is saving my day while debugging a crashing
apache. But matching the right request with the crash and its
corefile is difficult.
Have you taken a look at Jeff's mod_whatkilledus?
http://people.apache.org/~tr
Hi there,
Mod_log_forensic is saving my day while debugging a crashing
apache. But matching the right request with the crash and its
corefile is difficult.
Ideally the log would show me only the active requests
at the moment the server died. But in my case things are a bit
more difficult. The
On Dec 21, 2004, at 9:27 AM, Jeff Trawick wrote:
see patch
+1
* Jeff Trawick wrote:
> see patch
[...]
+1.
nd
--
> Rätselnd, was ein Anthroposoph mit Unterwerfung zu tun hat...
[...] Dieses Wort gibt so viele Stellen für einen Spelling Flame her, und
Du gönnst einem keine einzige.-- Jean Claude und David Kastrup in dtl
see patch
Index: src/modules/standard/mod_log_forensic.c
===
--- src/modules/standard/mod_log_forensic.c (revision 122969)
+++ src/modules/standard/mod_log_forensic.c (working copy)
@@ -189,7 +189,8 @@
if (!(id = ap_table_
Forwarded message:
>
> On Sat, 13 Nov 2004 17:23:34 -0800, Wilson Cheung <[EMAIL PROTECTED]> wrote:
> > apache-1.3.33: mod_log_forensic module use of assert() vs. ap_assert()
> > introduces __eprintf() gcc-ism?
>
> Thanks for the detailed diagnosis. There may not
Jeff Trawick wrote:
pid_t is long on Solaris
+1
Index: src/modules/standard/mod_log_forensic.c
===
RCS file: /home/cvs/apache-1.3/src/modules/standard/mod_lo
pid_t is long on Solaris
Index: src/modules/standard/mod_log_forensic.c
===
RCS file: /home/cvs/apache-1.3/src/modules/standard/mod_log_forensic.c,v
retrieving revision 1.7
diff -u -r1.7 mod_log_forensic.c
--- src/modules/standard/mod
Arghh!
sorry, hit the wrong button -- this should go deleted instead of sended!
>> this patch fixes compilation on Win32 for me since older SDK has no
>> unistd.h; and btw. I was also able to compile without unistd.h for
>> NetWare
>> target without warnings about missing prototypes, so maybe its
> this patch fixes compilation on Win32 for me since older SDK has no
> unistd.h; and btw. I was also able to compile without unistd.h for NetWare
> target without warnings about missing prototypes, so maybe its obsolete at
> all
archived as BZ #28572:
http://nagoya.apache.org/bugzilla/show_bug
Hi,
this patch fixes compilation on Win32 for me since older SDK has no unistd.h; and btw.
I was also able to compile without unistd.h for NetWare target without warnings about
missing prototypes, so maybe its obsolete at all
--- mod_log_forensic.c.orig Sat Feb 21 18:15:20 2004
+++ mod_l
At 06:49 AM 3/29/2004, Jeff Trawick wrote:
>Ben Laurie wrote:
>>Jeff Trawick wrote:
>
>>>solution 4: add some suitable API to APR 0.9 and implement on all platforms
>>
>>Surely not returning the value from the inc is broken anyway? And a harmless change
>>even if you don't consider it broken?
>
>a
Ben Laurie wrote:
Jeff Trawick wrote:
We could make the 2.0.x version require mod_unique_id.
that seems very reasonable
solution 4: add some suitable API to APR 0.9 and implement on all
platforms
Surely not returning the value from the inc is broken anyway? And a
harmless change even if you d
o Win32 section in apr/atomic in 0.9.
The Win32 implementation of atomics for 0.9 is apr_atomic.h.
> -> there needs to be done some apr work before porting mod_log_forensic.
What do you want to happen? Add a new increment API to 0.9 that returns
a value?
There would seem to be several
Jeff Trawick wrote:
2) Get approval to commit to stable branch
(no attempt made IIRC; typical action is to propose a vote in STATUS
file of stable branch and await comments or votes)
Done! Votes please...
--
http://www.apache-ssl.org/ben.html http://www.thebunker.net/
"There is no limit to
in 0.9.
The Win32 implementation of atomics for 0.9 is apr_atomic.h.
> -> there needs to be done some apr work before porting mod_log_forensic.
What do you want to happen? Add a new increment API to 0.9 that returns a value?
There would seem to be several solutions, some with APR dependenc
xt_id/apr_atomic_t next_id/
>
> YMMVslightly
Yes, slightly ;-)
apr_atomic_inc32 and apr_atomic_inc are not compatible,
most notable the interface of the latter is not thread safe.
Additionally there's no Win32 section in apr/atomic in 0.9.
-> there needs to be done some apr work before porting mod_log_forensic.
[cc [EMAIL PROTECTED]
nd
André Malo wrote:
* Jeff Trawick <[EMAIL PROTECTED]> wrote:
somehow I doubt there will be any problems at all getting it approved, but
nobody acted as a champion thus far and asked for approval themselves
In fact, I've thought it was by intention, because of the APR 1.0 atomic
calls ;-)
shouldn
* Jeff Trawick <[EMAIL PROTECTED]> wrote:
> somehow I doubt there will be any problems at all getting it approved, but
> nobody acted as a champion thus far and asked for approval themselves
In fact, I've thought it was by intention, because of the APR 1.0 atomic
calls ;-)
nd
Ben Laurie wrote:
How come it wasn't in 2.0.49?
(ancient news ;) we've been doing it this way for a long time)
a separate CVS branch is used for 2.0.x
here is the process for getting a fix/feature into 2.0.x:
1) commit to 2.1-dev.
(you already did that)
2) Get approval to commit to stable branc
How come it wasn't in 2.0.49?
Cheers,
Ben.
--
http://www.apache-ssl.org/ben.html http://www.thebunker.net/
"There is no limit to what a man can do or how far he can go if he
doesn't mind who gets the credit." - Robert Woodruff
--On Tuesday, December 30, 2003 3:41 PM + Ben Laurie <[EMAIL PROTECTED]>
wrote:
For review - or shall I just commit?
I'd say commit to HEAD (aka 2.1) right now. We can deal with merging back
into 2.0 once it has the 3 +1s (which imply it has been reviewed)... -- justin
For review - or shall I just commit?
Cheers,
Ben.
--
http://www.apache-ssl.org/ben.html http://www.thebunker.net/
"There is no limit to what a man can do or how far he can go if he
doesn't mind who gets the credit." - Robert Woodruff
/* =
45 matches
Mail list logo
