Hi, when I use apr_palloc function to allocate memory, should I check the
return value to make sure that I really got some memory? Is it possible that
return value is NULL? Documentation about the apr_palloc at
http://apr.apache.org/docs/apr/0.9/group__apr__pools.html says:
Allocate a block of
On Wed, 8 Apr 2009 22:07:55 +0300
Juha Korhonen mahtav...@gmail.com wrote:
Hi, when I use apr_palloc function to allocate memory, should I check
the return value to make sure that I really got some memory?
Yes.
Sort-of.
That is to say, yes you should, but it's common practice to omit
the
On 04/08/2009 10:13 PM, Nick Kew wrote:
On Wed, 8 Apr 2009 22:07:55 +0300
Juha Korhonenmahtav...@gmail.com wrote:
Hi, when I use apr_palloc function to allocate memory, should I check
the return value to make sure that I really got some memory?
Yes.
Sort-of.
That is to say, yes you
-Ursprüngliche Nachricht-
Von: Paul Querna
Gesendet: Dienstag, 7. April 2009 20:15
An: dev@httpd.apache.org
Betreff: Re: segfaults / core dumps caused by
ap_internal_fast_redirect
On Tue, Apr 7, 2009 at 10:01 AM, William A. Rowe, Jr.
wr...@rowe-clan.net wrote:
Plüm,
2009/4/8 KaiGai Kohei kai...@ak.jp.nec.com:
Graham Dumpleton wrote:
2009/4/8 KaiGai Kohei kai...@ak.jp.nec.com:
Graham Dumpleton wrote:
Explain first why using FASTCGI and suexec wouldn't be a better option?
Thease are limited to cgi applications, so we cannot apply such kind
of restriction
On 8 Apr 2009, at 03:27, Graham Dumpleton wrote:
[following up to Graham because two posts by him are all I have
in this thread]
2009/4/8 KaiGai Kohei kai...@ak.jp.nec.com:
Graham Dumpleton wrote:
Explain first why using FASTCGI and suexec wouldn't be a better
option?
Thease are limited
KaiGai Kohei wrote:
Graham Dumpleton wrote:
2009/4/8 KaiGai Kohei kai...@ak.jp.nec.com:
Graham Dumpleton wrote:
Explain first why using FASTCGI and suexec wouldn't be a better option?
Thease are limited to cgi applications, so we cannot apply such kind
of restriction on the built-in script
2009/4/8 KaiGai Kohei kai...@ak.jp.nec.com:
KaiGai Kohei wrote:
Graham Dumpleton wrote:
2009/4/8 KaiGai Kohei kai...@ak.jp.nec.com:
Graham Dumpleton wrote:
Explain first why using FASTCGI and suexec wouldn't be a better option?
Thease are limited to cgi applications, so we cannot apply such
Nick Kew wrote:
On 8 Apr 2009, at 03:27, Graham Dumpleton wrote:
[following up to Graham because two posts by him are all I have
in this thread]
2009/4/8 KaiGai Kohei kai...@ak.jp.nec.com:
Graham Dumpleton wrote:
Explain first why using FASTCGI and suexec wouldn't be a better option?
Graham Dumpleton wrote:
2009/4/8 KaiGai Kohei kai...@ak.jp.nec.com:
KaiGai Kohei wrote:
Graham Dumpleton wrote:
2009/4/8 KaiGai Kohei kai...@ak.jp.nec.com:
Graham Dumpleton wrote:
Explain first why using FASTCGI and suexec wouldn't be a better option?
Thease are limited to cgi applications,
On Wed, Apr 08, 2009 at 10:38:52AM +0900, KaiGai Kohei wrote:
I've posted my idea to improve web-application security a few times
however, it could not interest folks unfortunatelly. :(
So, I would like to offer another approach for the purpose.
The attached patch is a proof of the concept of
2009/4/8 KaiGai Kohei kai...@ak.jp.nec.com:
Graham Dumpleton wrote:
2009/4/8 KaiGai Kohei kai...@ak.jp.nec.com:
KaiGai Kohei wrote:
Graham Dumpleton wrote:
2009/4/8 KaiGai Kohei kai...@ak.jp.nec.com:
Graham Dumpleton wrote:
Explain first why using FASTCGI and suexec wouldn't be a better
On 8 Apr 2009, at 08:32, Joe Orton wrote:
So I'm not sure that it's worthwhile. Having said that, it seems a
lot
more worthwhile than the mod_privileges approach in the trunk, which
seems to claim it is secure so long as you don't execute untrusted
code,
so I'm not sure what threat model
Plüm, Rüdiger, VF-Group wrote:
I reviewed your patch and found some issues with it.
Thanks for your review and testing, Rüdiger. I assume you used and
adapted version of the sni_sslverifyclient-v5.diff patch, is that correct?
(All cases below use Name based virtual hosting and a non SNI
Joe Orton wrote:
On Wed, Apr 08, 2009 at 10:38:52AM +0900, KaiGai Kohei wrote:
I've posted my idea to improve web-application security a few times
however, it could not interest folks unfortunatelly. :(
So, I would like to offer another approach for the purpose.
The attached patch is a proof
On Wed, Apr 08, 2009 at 09:09:14AM +0100, Nick Kew wrote:
On 8 Apr 2009, at 08:32, Joe Orton wrote:
So I'm not sure that it's worthwhile. Having said that, it seems a
lot more worthwhile than the mod_privileges approach in the trunk,
which seems to claim it is secure so long as you don't
Graham Dumpleton wrote:
2009/4/8 KaiGai Kohei kai...@ak.jp.nec.com:
Graham Dumpleton wrote:
2009/4/8 KaiGai Kohei kai...@ak.jp.nec.com:
KaiGai Kohei wrote:
Graham Dumpleton wrote:
2009/4/8 KaiGai Kohei kai...@ak.jp.nec.com:
Graham Dumpleton wrote:
Explain first why using FASTCGI and suexec
The argstr_to_table function in util_script.c (r763283, current svn
trunk) is meant to convert a query string into an APR table. It
currently splits the query string up by the separator, then splits
the key and value by the = separator, then calls ap_unescape_url to
unescape the key and value.
[Please followup to d...@httpd.apache.org]
I've started a documentation page for using virtual hosts
over SSL with SNI at
http://wiki.apache.org/httpd/NameBasedSSLVHostsWithSNI
Comments are welcome, or make improvements directly on
the wiki.
--
Dan Poirier poir...@pobox.com
Colm MacCárthaigh wrote:
I don't think permitting hostname/number is a good idea, because a
hostname can map to multiple IPs, and it gets confusing, it's
non-standard :-) Right now the code just does a single lookup, and uses
that - so where there are multiple A/ records we'll have
Hello,
As we had a short discussion yesterday, we should rewind it to
the higher level viewpoint prior to implementation level.
I described it as follows, but it becomes a bit long sorry.
At the beginning, we can consider this proposition as an analogy
with identification, authentication and
Joe Orton wrote:
On Wed, Apr 08, 2009 at 09:09:14AM +0100, Nick Kew wrote:
On 8 Apr 2009, at 08:32, Joe Orton wrote:
So I'm not sure that it's worthwhile. Having said that, it seems a
lot more worthwhile than the mod_privileges approach in the trunk,
which seems to claim it is secure so
KaiGai Kohei wrote:
However, SElinux does not allow to revert its privilege (security context)
unconditionally, even if it is dynamically changed.
If we want to revert it, the security policy has to allow B-A in addition
to A-B, but it is generally nonsense.
It is also the reason why we need
William A. Rowe, Jr. wrote:
KaiGai Kohei wrote:
However, SElinux does not allow to revert its privilege (security context)
unconditionally, even if it is dynamically changed.
If we want to revert it, the security policy has to allow B-A in addition
to A-B, but it is generally nonsense.
It is
24 matches
Mail list logo
