Re: config is not read correctly
On Sun, Nov 16, 2008 at 00:51, Jos Ewert [EMAIL PROTECTED] wrote:
Hi,
Im trying to modify mod_fcgid to suit my needs, but I have a problem with
reading my newly added config directive.
For some reason it sets the config in my setter right but in the getter it
always reads the default value.
Whats even stranger is that I used this with mod_fcgid 1.10 too and it works.
e.g.
set :
config : 7092232, config-homedir : 7101472
get:
config : 7100440, config-homedir : 7845640
to set the value I use:
##
const char *set_homedir(cmd_parms *cmd, void *dirconfig,
const char *uid, const char *gid)
{
server_rec *s = cmd-server;
fcgid_server_conf *config =
ap_get_module_config(s-module_config, fcgid_module);
struct passwd *pw;
if((pw = getpwuid(ap_uname2id(uid))) == NULL){
fprintf(stderr,
Critical Error: You have specified an invalid user in
SuexecUserGroup.\n);
exit(1);
} else {
config-homedir = strdup(pw-pw_dir);
return NULL;
}
}
#
To get the config:
###
char *get_homedir(request_rec * r)
{
server_rec *s = r-server;
fcgid_server_conf *config =
ap_get_module_config(s-module_config, fcgid_module);
return config-homedir;
}
###
I removed all the debugging stuff I added to make it more readable.
if you want to take a look at the whole file + the other 2 I modified:
http://pastebin.com/f4c834a94
Any ideas what could have gone wrong?
r-server in get_homedir points to the server object corresponding to
the virtual host of the request. I _guess_ it is different from the
global server object. So, the ap_get_module_config in set_* and the
ap_get_module_config in get_* could give you two distinct config
objects.
S
Re: config is not read correctly
Ahhh found out what went wrong, I made a wrong merge. the local server config contained the right config , where the one that actually made it into the final config was the base config.
Re: Time for 2.2.11?
On 11/15/2008 09:50 PM, Ruediger Pluem wrote: Not that much time has passed since we released 2.2.10 (one month), but I would like to see a release of 2.2.11 in the near future. Why? 2.2.10 has two regressions, one against 2.2.8 (crashes caused by the proxy) which is already backported and one against 2.2.9 (errors in openssl detection) which is currently proposed for backport and misses two votes. There are two further changes in the STATUS file that only miss one additional vote. With these 3 changes in the pipeline and the 10 changes already done for 2.2.11 I think we have enough stuff for a release given the two regressions above. I even volunteer to be the RM for this release and if the remaining proposals get in I would like to TR on 29th / 30th of November and release on 6th / 7th of December if the voting passes. And yes I know some of us will be disappointed that some things will miss the boat again (especially SNI), but they wouldn't be in a 2.2.x release even if we do not release 2.2.11 at the beginning of December. Opinions? Given the positive feedback: Please vote now on the backports :-). Regards Rüdiger
Re: missing svn properties
Thanks for the observation. Fixed in r718015. Regards Rüdiger On 11/16/2008 02:23 AM, Takashi Sato wrote: In trunk these files are missing svn:eol-style native docs\manual\mod\mod_buffer.html docs\manual\mod\mod_buffer.html.en docs\manual\mod\mod_buffer.xml docs\manual\mod\mod_buffer.xml.meta docs\manual\mod\mod_privileges.html docs\manual\mod\mod_privileges.html.en docs\manual\mod\mod_privileges.xml docs\manual\mod\mod_privileges.xml.meta docs\manual\mod\mod_unixd.xml docs\manual\mod\mod_unixd.xml.meta modules\arch\unix\config5.m4 modules\arch\unix\mod_privileges.c modules\arch\unix\mod_unixd.c modules\filters\libsed.h modules\filters\mod_buffer.c modules\filters\mod_sed.c modules\filters\NWGNUmod_request modules\filters\regexp.c modules\filters\regexp.h modules\filters\sed.h modules\filters\sed0.c modules\filters\sed1.c server\mpm\simple\config.m4 server\mpm\simple\SIMPLE.README These are missing svn:keywords LastChangedRevision too docs\manual\mod\mod_buffer.xml docs\manual\mod\mod_privileges.xml docs\manual\mod\mod_unixd.xml Regards, Takashi
Re: missing svn properties
* Takashi Sato wrote: In trunk these files are missing [...] Go ahead. You don't need to ask for that ;) nd -- package Hacker::Perl::Another::Just;print [EMAIL PROTECTED] split/::/ =__PACKAGE__]}~; # André Malo # http://www.perlig.de #
developing custom authentication module
I am ISV developing a system that is using Apache. All the frontend's for system I am developing are all custom desktop applications, or web browsers controls wrapped in my own code. Thus users are not going to be entering username and password, the username and password used will be depended on which frontend being used. It is time for me to implement authentication correctly. I have two objectives with respect to authentication: 1: Protect my customers from unauthorized users. 2: Protect myself from customers hacking the authorization system to get access to features in which they have not purchased. #1 looks straight forward: If my impression is correct, I simply need to implement my own custom provider to check the custom username and password the frontends give it. Q: Is there documentation out there somewhere on how to implementing a new provider? #2 looks a lot more tricky. It seems that I will need to deviate from the normal way Apache's authentication works. For starters, NONE of the configuration can be in the http.conf, not like it is now with AuthType, AuthBasicProvider, etc. There is a Location directives in the conf that will have a custom directive for my custom Apache module. I would like to fully wire up this custom provider within this directive. To add to the complexity, there are different levels of authentication: None required, user, admin and there will be different locations under the Location directive for each, again, this all needs to be wired up in code when the custom directive for my custom Apache module is called. Q: Any suggestions on how I might achieve this? Sam P.S. I do NOT own the book on writing Apache Module in 2.0, just the older 1.3 book. Would any of this be addressed in that book?
Re: svn commit: r717867 - in /httpd/httpd/trunk: CHANGES docs/manual/mod/mod_buffer.xml docs/manual/mod/mod_buffer.xml.meta modules/filters/config.m4 modules/filters/mod_buffer.c
On 11/16/2008 12:58 AM, Graham Leggett wrote:
Ruediger Pluem wrote:
+/* Do nothing if asked to filter nothing. */
+if (APR_BRIGADE_EMPTY(bb)) {
+return ap_pass_brigade(f-next, bb);
+}
Hm. This changes the order in which we sent the brigades (provided we
have already buffered something).
I am not sure if this causes any harm down the chain or not.
Wouldn't it be more sane in this case to add the empty brigade to
our buffer?
In theory no, because the brigade you are passing is empty. You can send
empty brigades in any order, it will make no difference. Adding an empty
brigade to our buffer is effectively a noop.
Thinking about this, sending an empty brigade down the filter stack
might be pointless as well, could we just return APR_SUCCESS? (Unless
there is an expectation that an empty brigade should hit all the filters
in the stack, in which case the code is correct as it is.)
I would tend to say that an empty brigade should hit the filters as well.
I would say lets continue with the code as is and see if we hit any problems.
+/* pass what we have down the chain */
+rv = ap_pass_brigade(f-next, ctx-bb);
For sanity reasons I would add an apr_brigade_cleanup(ctx-bb) here.
Hmm... I am not sure. If the rest of the filter stack chose not to
consume the whole brigade for whatever reason, the unconsumed content
would remain in the buffer ready for the next pass, or would be cleaned
up when the request is aborted.
I could find no precedent in any of the other filters for proactively
emptying the brigade once it had been passed down the stack. In 99.9% of
cases, you would be emptying an empty brigade, which is a waste.
As said it is a sanity measure. If a filter decides not to consume the whole
brigade it must set it aside and store it somewhere in the context.
apr_brigade_cleanup ensures that nothing bad happens if the filter down
the chain forgot to remove the set aside buckets from the passed brigade.
Yes, this would be a bug in downstream filter.
I admit that filters normally don't do this and only handlers implement
this safety measure. So it is debatable whether to do it or not.
I think this is suboptimal in many ways:
1. We should only do this on heap buckets. For other buckets we don't
even know
that we waste memory and in this case we create unneeded memory
copy operations.
This part gets extremely bad when we have a file bucket. Yes, I
understand the
intentions of this module and have knowledge about buckets and
brigades, but the
normal user has not. So the user might think it is a good idea to
use this filter
in case of static files. So at least a warning should be added to
the documentation
that this is counter productive when serving files.
I disagree.
The purpose of this module was to handle a page that consists of many
(tens to hundreds) of mod_include files, in a nested fashion. The output
on the wire consists of lots of short ( 10 bytes) file buckets, and
lots of short file buckets that have been morphed into short heap
buckets by mod_include (thank you indentation). This ends up on the wire
as lots of chunks, each a few bytes long, taking up 8k * number of
few-bytes-chunks per request in RAM, and wasting lots of bandwidth in
chunk headers.
If file buckets were passed as is, much of the optimisation would be
lost, because you would have a short-and-inefficient heap bucket,
followed by a short file bucket, followed by a short-and-inefficient
heap bucket. Using the current implementation, all three buckets are
collapsed down to just one.
To be clear on what the filter does, it implements a buffer, and it
works like a buffer according got the principle of least astonishment.
It is completely optional, and not enabled by default.
The module does not pretend to be relevant in every use case, and is
particularly not relevant for cases that are efficient already (simple
static files + sendfile, for example).
Thanks for clarification. Nevertheless we should make it more clear in the
documentation that this module can make performance worse if used in the
wrong context, e.g. with static files. Otherwise users might think that
buffering files via mod_buffer could be a cool performance boost which
it is not.
2. If we have a large heap bucket (= APR_BUCKET_BUFF_SIZE) or one
that doesn't fit into
the remaining buffer of the last heap heap bucket in ctx-bb
apr_bucket_write creates
a new heap bucket and thus causes the memory to be copied over from
the old bucket to
the new bucket. We should set an intelligent flush function for
apr_brigade_write
that prevents this and just moves over this bucket from bb to
ctx-bb (the transient
bucket created by apr_brigade_write is not a big loss in this case).
Again, we are trying to second guess what the admin is trying to do.
If the response contained large heap buckets, then the correct
Re: Time for 2.2.11?
On Nov 15, 2008, at 3:50 PM, Ruediger Pluem wrote: Not that much time has passed since we released 2.2.10 (one month), but I would like to see a release of 2.2.11 in the near future. Why? 2.2.10 has two regressions, one against 2.2.8 (crashes caused by the proxy) which is already backported and one against 2.2.9 (errors in openssl detection) which is currently proposed for backport and misses two votes. There are two further changes in the STATUS file that only miss one additional vote. With these 3 changes in the pipeline and the 10 changes already done for 2.2.11 I think we have enough stuff for a release given the two regressions above. I even volunteer to be the RM for this release and if the remaining proposals get in I would like to TR on 29th / 30th of November and release on 6th / 7th of December if the voting passes. +1... I also volunteer as well, if you get too busy...
Re: Time for 2.2.11?
Ruediger Pluem wrote: On 11/15/2008 09:50 PM, Ruediger Pluem wrote: Not that much time has passed since we released 2.2.10 (one month), but I would like to see a release of 2.2.11 in the near future. Why? 2.2.10 has two regressions, one against 2.2.8 (crashes caused by the proxy) which is already backported and one against 2.2.9 (errors in openssl detection) which is currently proposed for backport and misses two votes. There are two further changes in the STATUS file that only miss one additional vote. With these 3 changes in the pipeline and the 10 changes already done for 2.2.11 I think we have enough stuff for a release given the two regressions above. I even volunteer to be the RM for this release and if the remaining proposals get in I would like to TR on 29th / 30th of November and release on 6th / 7th of December if the voting passes. And yes I know some of us will be disappointed that some things will miss the boat again (especially SNI), but they wouldn't be in a 2.2.x release even if we do not release 2.2.11 at the beginning of December. Opinions? Given the positive feedback: Please vote now on the backports :-). I /really/ want to see a sub-second proxy connection timeout as this is needed due to Windows' inappropriate RFC interpretation. This would be r705005 produced by Ruediger, I believe. If this is not part of 2.2.11 (I'm pretty sure it did not go into 2.2.10) then I'm going to have to backport this myself into our binaries for real soon here and keep doing so with each new 2.2.x. It would be /much/ better to just have this in 2.2.x. -- Jess Holle
Re: Time for 2.2.11?
ess Holle schrieb: Ruediger Pluem wrote: On 11/15/2008 09:50 PM, Ruediger Pluem wrote: Given the positive feedback: Please vote now on the backports :-). I /really/ want to see a sub-second proxy connection timeout as this is needed due to Windows' inappropriate RFC interpretation. This would be r705005 produced by Ruediger, I believe. If this is not part of 2.2.11 (I'm pretty sure it did not go into 2.2.10) then I'm going to have to backport this myself into our binaries for real soon here and keep doing so with each new 2.2.x. It would be /much/ better to just have this in 2.2.x. This has already been backported to 2.2.x on November 11th: http://svn.apache.org/viewvc?view=revrevision=713145 and http://mail-archives.apache.org/mod_mbox/httpd-cvs/200811.mbox/[EMAIL PROTECTED] Regards, Rainer
Re: Time for 2.2.11?
Cool. Thanks! I'll anxiously await 2.2.11 then. Rainer Jung wrote: Jess Holle schrieb: Ruediger Pluem wrote: On 11/15/2008 09:50 PM, Ruediger Pluem wrote: Given the positive feedback: Please vote now on the backports :-). I /really/ want to see a sub-second proxy connection timeout as this is needed due to Windows' inappropriate RFC interpretation. This would be r705005 produced by Ruediger, I believe. If this is not part of 2.2.11 (I'm pretty sure it did not go into 2.2.10) then I'm going to have to backport this myself into our binaries for real soon here and keep doing so with each new 2.2.x. It would be /much/ better to just have this in 2.2.x. This has already been backported to 2.2.x on November 11th: http://svn.apache.org/viewvc?view=revrevision=713145 and http://mail-archives.apache.org/mod_mbox/httpd-cvs/200811.mbox/[EMAIL PROTECTED] Regards, Rainer
Re: svn commit: r717867 - in /httpd/httpd/trunk: CHANGES docs/manual/mod/mod_buffer.xml docs/manual/mod/mod_buffer.xml.meta modules/filters/config.m4 modules/filters/mod_buffer.c
Ruediger Pluem wrote: Thanks for clarification. Nevertheless we should make it more clear in the documentation that this module can make performance worse if used in the wrong context, e.g. with static files. Otherwise users might think that buffering files via mod_buffer could be a cool performance boost which it is not. I have added a warning to the docs to better explain just what the buffer does, and that it is not going to help in cases where the response is already efficient. You can have a mixture of both because there can be include files in your nested include files that have a larger chunk while many other are as small as you describe. IMHO by taking care of this case you don't loose any of your buffer features as the resulting brigade is nearly the same with the difference that we just recreated and mem copied the buckets we had before. The only difference that matters appears in the case of a small file bucket that did not fit in the previous heap bucket. IMHO you put too much burden on the administrator to know the internals of httpd in order to make a good decision whether to use mod_buffer or not. In theory the administrator can try mod_buffer, and if it makes it faster, all well and good, if it doesn't oh well. I took quite a while looking at this, most specifically a potential optimisation where if the heap bucket you were adding was already 8k in size, just add the bucket and don't repack. But whichever way I looked at it, I could see potential for the optimisation to be lost. I think further optimisations should probably come with switches to control how they work. The point behind the buffer is to convert whatever buckets are present into the smallest number of heap buckets as possible, and do this until the buffer is full, or the response is complete, whichever comes first. Think of a potentially expensive bucket of known but long length - we certainly don't want to blindly move the expensive bucket over in this case, as the bucket will only get read at some point in the distance future when the slow client gets round to read the bucket, and the whole purpose of buffering is lost. Could you please elaborate of which kind of expensive bucket you are talking about? One example is data reverse proxied from an expensive backend and then built into a page using mod_include. By reading the full response in before doing the blocking sending it to the client, you give your backend a fighting chance to release resources immediately rather than ages later when the network eventually gets round to accepting the data. When the proxy is optimised to release the backend connection when the EOS is read from the backend, rather than after the EOS is successfully delivered downstream, this will help for normal reverse proxied data too. My assumption is that we deal with heap buckets in most cases, but anyway this problem can be solved by checking APR_BRIGADE_EMPTY(ctx-bb) APR_BUCKET_IS_HEAP(e) and proceed in the current way if this is not true. I looked at this again, we can extend the optimisation beyond just the first bucket on condition the buckets stay heap buckets, and stay APR_BUCKET_BUFF_SIZE in length. This way if someone buffers a file (or other potentially large bucket), the copy is avoided, and we stick with a move. Regards, Graham -- smime.p7s Description: S/MIME Cryptographic Signature
Re: svn commit: r718082 - /httpd/httpd/trunk/modules/filters/mod_buffer.c
Ruediger Pluem wrote:
+/* pass flush and metadata buckets through */
+if (APR_BUCKET_IS_FLUSH(e) || APR_BUCKET_IS_METADATA(e)) {
This is redundant as flush buckets are metadata buckets :-).
+APR_BUCKET_REMOVE(e);
+APR_BRIGADE_INSERT_TAIL(bb, e);
+continue;
+}
Hmmm... true. A metadata bucket should be passed over into the buffer,
but flush buckets should cause the buffer to be read straight away. Will
fix.
Regards,
Graham
--
smime.p7s
Description: S/MIME Cryptographic Signature
Bug report for Apache httpd-1.3 [2008/11/16]
+---+ | Bugzilla Bug ID | | +-+ | | Status: UNC=Unconfirmed NEW=New ASS=Assigned| | | OPN=ReopenedVER=Verified(Skipped Closed/Resolved) | | | +-+ | | | Severity: BLK=Blocker CRI=Critical REG=Regression MAJ=Major | | | | MIN=Minor NOR=NormalENH=Enhancement TRV=Trivial | | | | +-+ | | | | Date Posted | | | | | +--+ | | | | | Description | | | | | | | |10744|New|Nor|2002-07-12|suexec might fail to open log file| |10747|New|Maj|2002-07-12|ftp SIZE command and 'smart' ftp servers results i| |10760|New|Maj|2002-07-12|empty ftp directory listings from cached ftp direc| |14518|Opn|Nor|2002-11-13|QUERY_STRING parts not incorporated by mod_rewrite| |16013|Opn|Nor|2003-01-13|Fooling mod_autoindex + IndexIgnore | |16631|Inf|Min|2003-01-31|.htaccess errors logged outside the virtual host l| |17318|Inf|Cri|2003-02-23|Abend on deleting a temporary cache file if proxy | |19279|Inf|Min|2003-04-24|Invalid chmod options in solaris build| |21637|Inf|Nor|2003-07-16|Timeout causes a status code of 200 to be logged | |21777|Inf|Min|2003-07-21|mod_mime_magic doesn't handle little gif files| |22618|New|Maj|2003-08-21|MultiViews invalidates PATH_TRANSLATED if cgi-wrap| |25057|Inf|Maj|2003-11-27|Empty PUT access control in .htaccess overrides co| |26126|New|Nor|2004-01-14|mod_include hangs with request body | |26152|Ass|Nor|2004-01-15|Apache 1.3.29 and below directory traversal vulner| |26790|New|Maj|2004-02-09|error deleting old cache file | |29257|Opn|Nor|2004-05-27|Problem with apache-1.3.31 and mod_frontpage (dso,| |29498|New|Maj|2004-06-10|non-anonymous ftp broken in mod_proxy | |29538|Ass|Enh|2004-06-12|No facility used in ErrorLog to syslog| |30207|New|Nor|2004-07-20|Piped logs don't close read end of pipe | |30877|New|Nor|2004-08-26|htpasswd clears passwd file on Sun when /var/tmp i| |30909|New|Cri|2004-08-28|sporadic segfault resulting in broken connections | |31975|New|Nor|2004-10-29|httpd-1.3.33: buffer overflow in htpasswd if calle| |32078|New|Enh|2004-11-05|clean up some compiler warnings | |32539|New|Trv|2004-12-06|[PATCH] configure --enable-shared= brocken on SuSE| |32974|Inf|Maj|2005-01-06|Client IP not set | |33086|New|Nor|2005-01-13|unconsistency betwen 404 displayed path and server| |33495|Inf|Cri|2005-02-10|Apache crashes with WSADuplicateSocket failed for| |33772|New|Nor|2005-02-28|inconsistency in manual and error reporting by sue| |33875|New|Enh|2005-03-07|Apache processes consuming CPU| |34108|New|Nor|2005-03-21|mod_negotiation changes mtime to mtime of Document| |34114|New|Nor|2005-03-21|Apache could interleave log entries when writing t| |34404|Inf|Blk|2005-04-11|RewriteMap prg can not handle fpout | |34571|Inf|Maj|2005-04-22|Apache 1.3.33 stops logging vhost| |34573|Inf|Maj|2005-04-22|.htaccess not working / mod_auth_mysql| |35424|New|Nor|2005-06-20|httpd disconnect in Timeout on CGI| |35439|New|Nor|2005-06-21|Problem with remove /../ in util.c and mod_rewri| |35547|Inf|Maj|2005-06-29|Problems with libapreq 1.2 and Apache::Cookie | |3|New|Nor|2005-06-30|Can't find DBM on Debian Sarge| |36375|Opn|Nor|2005-08-26|Cannot include http_config.h from C++ file| |37166|New|Nor|2005-10-19|Under certain conditions, mod_cgi delivers an empt| |37185|New|Enh|2005-10-20|AddIcon, AddIconByType for OpenDocument format| |37252|New|Reg|2005-10-26|gen_test_char reject NLS string | |38989|New|Nor|2006-03-15|restart + piped logs stalls httpd for 24 minutes (| |39104|New|Enh|2006-03-25|[FR] fix build with -Wl,--as-needed | |39287|New|Nor|2006-04-12|Incorrect If-Modified-Since validation (due to syn| |39937|New|Nor|2006-06-30|Garbage output if README.html is gzipped or compre| |40176|New|Nor|2006-08-03|magic and mime| |40224|Ver|Nor|2006-08-10|System time crashes Apache @year 2038 (win32 only?| |41279|New|Nor|2007-01-02|Apache 1.3.37 htpasswd is vulnerable to buffer ove| |42355|New|Maj|2007-05-08|Apache 1.3 permits non-rfc HTTP error code = 600 | |43626|New|Maj|2007-10-15|r-path_info returning invalid value |
Re: Introducing mod_privileges for Apache HTTPD
Hello, Nick It seems to me we have similar ideas to enhance web-application security. I've focused on SELinux to utilize security features of operating system. I had a plan to start discussion after my PostgreSQL works are closed, but, it is a good time to start discussion to utilize them for web-applications. I have a modified version of apache/httpd, as a proof of concept. http://code.google.com/p/sepgsql/source/browse/misc/httpd-selinux/ (*) Please copy the 2.2.x directory as server/mpm/selinux, and append --with-mpm=selinux It enables to invoke request handlers with individual privilege set based on http-authenticated username, source IP addresses and so on. The typical flow of operations are as follows: 1. It receives a HTTP request come from client. 2. It generates a one-time thread to handle the request. The parent side wait for completion of the thread. 3. The one-time thread assigns itself a proper privilege set based on the http-authentication and so on. 4. It invokes request handlers to process the given request. The request handler works within more restricted privileges. When it kick PHP scripts or static contents handlers, the restricted privileges are inherited. 5. The one-time thread returns a http response to the client, then it dies soon. 6. The parent wakes up, and returns to (1). (*) Please note that SELinux disallow to revert privileges, because it can be a vulnerability of unexpected escalation. Your mod_privileges is implemented on the perchild MPM. It is suitable to achieve per VirtualHost privileges. In addition, I think per user/request/network privileges enforced by operating system is more worthwhile feature. A security focused MPM is a key facility to enable the idea. I assume it does not give first priority for performances, but it enables to resolves some kinds of security nightmares. How do you think the concept? Please any comment, Thanks, Nick Kew wrote: I've just introduced mod_privileges to Apache HTTPD trunk. This is a platform-specific module for Solaris 10 and OpenSolaris, that makes the webserver privileges(5)-aware. This enables the server to be run with enhanced security, and with different settings per virtual host. The feature likely to be of most interest is that it enables different virtual hosts to run under different Unix user and group IDs, using the VHostUser and VHostGroup directives. This is the capability once promised by the perchild MPM. It has one major drawback: it is not suitable for a threaded MPM. However, it is ideally suited for use with PHP, which of course also precludes threads. It should also be of interest to anyone hosting other in-process scripting environments such as mod_perl, mod_python or mod_ruby, or application modules. http://svn.apache.org/viewvc/httpd/httpd/trunk/modules/arch/unix/mod_privileges.c http://svn.apache.org/viewvc/httpd/httpd/trunk/docs/manual/mod/mod_privileges.xml -- OSS Platform Development Division, NEC KaiGai Kohei [EMAIL PROTECTED]
