Re: Multiple AAA providers
Justin Erenkrantz said: I still maintain the better way to do this is to handle it in the provider modules themselves by leveraging the provider API instead. To reiterate, in my mind, the ideal syntax is: Location /foo LDAPProvider ldap1 ...config options for mod_authnz_ldap... /LDAPProvider LDAPProvider ldap2 ...config options for mod_authnz_ldap... /LDAPProvider DBDProvider my_db ...config options for hypothetical mod_authn_dbd... /DBDProvider ...config options for mod_authnz_ldap... AuthUserFile conf/foo AuthBasicProvider ldap1 ldap2 ldap file my_db /Location This isolates the config directly to the module, and if we so desire, we could add helper functions which promote re-use of this strategy by other provider modules as needed. -- justin This means that: - Every auth module has to be independantly updated to use this method (which won't happen) - Every module will have it's own method of configuring multiple providers. Putting my end user hat on, doing it the way you suggest would irritate me no end, as it would make no logical sense to me why one auth provider allows multiple configurations and another doesn't, or why one auth provider uses one config mechanism and another auth provider uses a different one. I definitely think that getting the auth framework to understand this syntax is the right way to go, we just need to figure out that magic syntax that will work elegantly. Regards, Graham --
relatively minor 2.1 API change
worker_score in scoreboard.h needs a pid_t field. The worker MPM (and probably some other Unix threaded MPMs) has a perhaps-unexpected way of handling child processes which are terminating gracefully -- it allows new child processes to take over the process_score structure and the worker_score structure for all threads except for the ones handling long-running requests in the old child process. Because there is not a pid_t field in worker_score, mod_status can't display the id of the process handling that particular request, which makes it difficult to determine which requests are being handled by some httpd process which is trying to terminate. So step 1 is add the pid_t field and bump MMN. Step 2 is to teach worker MPM to maintain it properly. Step 3 is to teach mod_status to check that field for non-zero (i.e., implemented by MPM) and , if set, use that instead of the process_score field. Any concerns?
Re: modules that register hooks after the register_hooks call-back is finished
On Thu, 3 Mar 2005 06:59:43 -0500, Jeff Trawick [EMAIL PROTECTED] wrote: is this a normal idiom? is there a point prior to normal request processing where it is safe to walk through the hooks to figure stuff out? should we document that register_hooks is the one place to do that? assert(Modules can't register hooks after apr_hooks_sort() has been called. So hook registration does need to be limited to the register-hooks call-back. Any module that behaves otherwise is going to cause undefined behavior.)
Re: Authentication Needs for Apache: Was Re: Puzzling News
Hi. Thanks for this. I've been tied up with a couple of things, so please pardon the delay. As far as this goes, Erik is correct, to a point!-) Just for tightness, I want to make this as clear as mud!-) To my read, and this meshes with others, SAML is open. RSA http://www.oasis-open.org/committees/security/ipr.php have four patents that seem to overlap with parts of SAML, from: ...RSA believed that these four patents could be relevant to practicing certain operational modes of the OASIS Security Assertion Markup Language (SAML) specifications Liberty Alliance took the SAML spec and implemented it with a profile that extended it, called the Browser/POST profile (a form post encoded in SAML). It is this profile that RSA seem to be claiming http://lists.oasis-open.org/archives/security-services/200205/ msg00046.html rather than the SAML spec which is open: http://www.opensaml.org/license.html It is most unfortunate that RSA are taking this stance, but SAML and another synch method would not be covered by this patent, in my limited understanding of the world. Internet2, for the record, do hold an RSA license which covers all users of the app. s On 1 Mar 2005, at 16:51, Erik Abele wrote: On 01.03.2005, at 15:52, Sean Mehan wrote: Just a pointer to something that is gaining a bit of ground in various circles: http://www.oasis-open.org/committees/download.php/11511/sstc-saml- tech-overview-2.0-draft-03.pdf found at http://www.oasis-open.org/committees/documents.php?wg_abbrev=security This is about SAML, a vocabulary for exchange of authentication and authorization data about users trying to access resources. With this capability built in, one can write policies for users originating from other sites. The problem I see with SAML and it's specs is that RSA holds patents on it and although these patens are made available under a royalty-free license, every end-user must obtain their own licsense from RSA. That alone is a requirement which goes far beyond the requirements of the Apache License and furthermore there are some other constraints (e.g. licensees must grant RSA the same rights to any patents they own). Find the details at http://www.oasis-open.org/committees/security/ipr.php. There is an implementation of this for what used to be called (resource) targets, now called SP [service provider]s, which compiles and runs under apache 1.3/2.0 found at http://shibboleth.internet2.edu/ Hmm, I think both, opensaml.org and shibboleth.internet2.edu are not conforming to RSA's license requirements: The license terms for the RSA Patents will permit end-users to use the Licensed Products. However, in the event that a Licensed Product is a product (such as a toolkit product or operating system service) that is used to develop other products, the license will require the licensee of the RSA Patents to notify users of the Licensed Products that such users must obtain a license directly from RSA for the RSA Patents. RSA is willing to grant such licenses on the same non-exclusive, royalty-free terms described above. I don't find any such notice on both pages, just their usual license which is misleading in this case, e.g. http://www.opensaml.org/license.html IMHO we should avoid touching this sort of stuff... Cheers, Erik
Re: Multiple AAA providers
Actually I think the better syntax would be: AuthProviderAlias ldap Myldap1 ...config options for mod_authnz_ldap... /AuthProviderAlias AuthProviderAlias ldap Myldap2 ...config options for mod_authnz_ldap... /AuthProviderAlias AuthProviderAlias file Myfile1 ...config options for mod_auth... /AuthProviderAlias Location /foo1 AuthProvider Myldap1 Myfile1 ...Other config options... /Location Location /foo2 AuthProvider Myldap2 Myfile1 ...Other config options... /Location Location /foo3 AuthProvider Myldap1 Myldap2 ...Other config options... /Location This would allow you to mix-match-reuse-redefine auth configurations anywhere you like. I haven't thought this through completely from an implementation standpoint, but by moving the provider definitions into mod_auth_basic and then extending the framework for handling multiple provider definitions into the providers themselves, I think we can come out with something very useful and reuseable. Brad [EMAIL PROTECTED] Friday, March 04, 2005 1:06:47 AM Justin Erenkrantz said: I still maintain the better way to do this is to handle it in the provider modules themselves by leveraging the provider API instead. To reiterate, in my mind, the ideal syntax is: Location /foo LDAPProvider ldap1 ...config options for mod_authnz_ldap... /LDAPProvider LDAPProvider ldap2 ...config options for mod_authnz_ldap... /LDAPProvider DBDProvider my_db ...config options for hypothetical mod_authn_dbd... /DBDProvider ...config options for mod_authnz_ldap... AuthUserFile conf/foo AuthBasicProvider ldap1 ldap2 ldap file my_db /Location This isolates the config directly to the module, and if we so desire, we could add helper functions which promote re-use of this strategy by other provider modules as needed. -- justin This means that: - Every auth module has to be independantly updated to use this method (which won't happen) - Every module will have it's own method of configuring multiple providers. Putting my end user hat on, doing it the way you suggest would irritate me no end, as it would make no logical sense to me why one auth provider allows multiple configurations and another doesn't, or why one auth provider uses one config mechanism and another auth provider uses a different one. I definitely think that getting the auth framework to understand this syntax is the right way to go, we just need to figure out that magic syntax that will work elegantly. Regards, Graham --
Re: Multiple AAA providers
--On Friday, March 4, 2005 8:56 AM -0700 Brad Nicholes [EMAIL PROTECTED] wrote: Actually I think the better syntax would be: AuthProviderAlias ldap Myldap1 ...config options for mod_authnz_ldap... /AuthProviderAlias AuthProviderAlias ldap Myldap2 ...config options for mod_authnz_ldap... /AuthProviderAlias AuthProviderAlias file Myfile1 ...config options for mod_auth... /AuthProviderAlias Location /foo1 AuthProvider Myldap1 Myfile1 ...Other config options... /Location Location /foo2 AuthProvider Myldap2 Myfile1 ...Other config options... /Location Location /foo3 AuthProvider Myldap1 Myldap2 ...Other config options... /Location This would allow you to mix-match-reuse-redefine auth configurations anywhere you like. I haven't thought this through completely from an implementation standpoint, but by moving the provider definitions into mod_auth_basic and then extending the framework for handling multiple provider definitions into the providers themselves, I think we can come out with something very useful and reuseable. Actually, I think we could move this into a (new) mod_authn_alias/config or something and make it generic - tieing it into mod_auth_basic would mean it couldn't be used by mod_auth_digest. The key here from the implementation perspective is that we would know what the 'real' provider name is as well - so we wouldn't have to tie it to the module. mod_authn_alias would register a 'fake' provider that merges the auth's per_dir_config before executing the 'real' provider. So, yah, I like this. -- justin
Re: Multiple AAA providers
At 01:30 AM 3/4/2005, Justin Erenkrantz wrote: On Thu, Mar 03, 2005 at 08:40:22PM -0600, William A. Rowe, Jr. wrote: And attached is the module for comment. I have no time till this weekend if then, so I've got the build system changes and will commit if we like. My question as to how this would interact with the auth providers is still unanswered. Correct. Needs Study. Remember that the auth providers don't implement the check_user_id hook - only the auth mechanisms (basic/digest) implement those hooks. So, this module acts counter to the entire notion of providers by just blindly re-running the entire hook process instead. (check_user_id now becomes recursive - yikes!) Actually, to depth == 1. We have a recursion block to prevent further recursion. One interesting side effect on this patch. If we don't find the auth we required in the specific per-dir config, we unset it before we return declined from the module. If a provider accepts, we leave that per-dir config set (that -is- where we were authorized!) The side effect is this, on the subsequent hooks, per-dir still points at this second provider, so now we leverage the identical config for gaining groups, fixups and other such tweakage. Remember, we -only- recursed IIF everyone on pass one declined. Our hook isn't invoked at all because it's RUN_FIRST, and if someone is willing to authenticate the user, we succeed. We'd now incur the overhead of the auth mechanism hooks when there is little need to do so. No overhead, anything but DECLINED drops us out of the hook. Plus, we lose the ability to sanely chain providers as was the original intent. Agreed - this - is what needs study. I still maintain the better way to do this is to handle it in the provider modules themselves by leveraging the provider API instead. NO and I will veto. IF you introduce code complexity into seven provider modules which could be made more complex in the core, in a single add-in module, or extending only the basic/digest provider, then you are rolling dice in one area I don't like to play poker. To reiterate, in my mind, the ideal syntax is: Location /foo LDAPProvider ldap1 ...config options for mod_authnz_ldap... /LDAPProvider LDAPProvider ldap2 ...config options for mod_authnz_ldap... /LDAPProvider DBDProvider my_db ...config options for hypothetical mod_authn_dbd... /DBDProvider ...config options for mod_authnz_ldap... AuthUserFile conf/foo AuthBasicProvider ldap1 ldap2 ldap file my_db /Location This isolates the config directly to the module, and if we so desire, we could add helper functions which promote re-use of this strategy by other provider modules as needed. -- justin Unnecessarily complicates all the providers. What about AuthConfig LDAP ldap1 ... AuthConfig LDAP ldap2 ... AuthBasicProvider ldap1 ldap2 file my_db where we teach auth_basic and only auth_basic about AuthConfig sections, and keep the cruft out of each and every provider instance? Bill
Re: relatively minor 2.1 API change
At 04:20 AM 3/4/2005, Jeff Trawick wrote: worker_score in scoreboard.h needs a pid_t field. As long as you store the pid:tid atom, I'm +1. Quite right, those tid's can become somewhat meaningless out of context. Bill
Re: Multiple AAA providers
At 11:14 AM 3/4/2005, Justin Erenkrantz wrote: --On Friday, March 4, 2005 8:56 AM -0700 Brad Nicholes [EMAIL PROTECTED] wrote: Actually I think the better syntax would be: AuthProviderAlias ldap Myldap1 ...config options for mod_authnz_ldap... /AuthProviderAlias AuthProviderAlias ldap Myldap2 ...config options for mod_authnz_ldap... /AuthProviderAlias AuthProviderAlias file Myfile1 ...config options for mod_auth... /AuthProviderAlias Seems AuthAlias file Foo would be simpler to grok and less simple to mistype. This would allow you to mix-match-reuse-redefine auth configurations anywhere you like. I agree provided Location /foo AuthAlias ldap ldap1 Location /foo/secure AuthAlias ldap ldap1 does the right thing for /foo/secure/... and it's trivial enough to make sure that happens. Actually, I think we could move this into a (new) mod_authn_alias/config or something and make it generic Hmmm Hmmm... yup, that's what I did... - tieing it into mod_auth_basic would mean it couldn't be used by mod_auth_digest. but you lose the control offered by AuthBasicProvider ... that was a good suggestion. mod_authn_alias would register a 'fake' provider that merges the auth's per_dir_config before executing the 'real' provider. yup, that's what mod_auth_config did. However, mod_auth_config; 1. invokes auth for the local directives (not Auth sectioned) 2. invokes auth for all Auth sections. providing the explicit list in AuthBasicProvider would ensure we walk the provider configs correctly.
Re: Multiple AAA providers
--On Friday, March 4, 2005 11:27 AM -0600 William A. Rowe, Jr. [EMAIL PROTECTED] wrote: yup, that's what mod_auth_config did. However, mod_auth_config; 1. invokes auth for the local directives (not Auth sectioned) 2. invokes auth for all Auth sections. providing the explicit list in AuthBasicProvider would ensure we walk the provider configs correctly. No, the module that was posted had no concept of providers. The right place to do this is at the provider level not the hook level. -- justin
Re: relatively minor 2.1 API change
On Mar 4, 2005, at 5:20 AM, Jeff Trawick wrote: worker_score in scoreboard.h needs a pid_t field. The worker MPM (and probably some other Unix threaded MPMs) has a perhaps-unexpected way of handling child processes which are terminating gracefully -- it allows new child processes to take over the process_score structure and the worker_score structure for all threads except for the ones handling long-running requests in the old child process. Because there is not a pid_t field in worker_score, mod_status can't display the id of the process handling that particular request, which makes it difficult to determine which requests are being handled by some httpd process which is trying to terminate. So step 1 is add the pid_t field and bump MMN. Step 2 is to teach worker MPM to maintain it properly. Step 3 is to teach mod_status to check that field for non-zero (i.e., implemented by MPM) and , if set, use that instead of the process_score field. +1
Re: Multiple AAA providers
At 11:34 AM 3/4/2005, Justin Erenkrantz wrote: --On Friday, March 4, 2005 11:27 AM -0600 William A. Rowe, Jr. [EMAIL PROTECTED] wrote: yup, that's what mod_auth_config did. However, mod_auth_config; 1. invokes auth for the local directives (not Auth sectioned) 2. invokes auth for all Auth sections. providing the explicit list in AuthBasicProvider would ensure we walk the provider configs correctly. No, the module that was posted had no concept of providers. The right place to do this is at the provider level not the hook level. -- justin We have a naming problem. Provider is meaningless. Is a provider Basic, Digest? Or is a provider File, DBM, LDAP? If you mean the former, I'm right there with you. However, that won't work on antique (2.0, even 1.3) auth modules, so my concept is still valid. It should simply be replaced for httpd-2.0 with something clearer :) Bill
Re: relatively minor 2.1 API change
On Fri, 04 Mar 2005 11:15:25 -0600, William A. Rowe, Jr.
[EMAIL PROTECTED] wrote:
At 04:20 AM 3/4/2005, Jeff Trawick wrote:
worker_score in scoreboard.h needs a pid_t field.
As long as you store the pid:tid atom, I'm +1. Quite right,
those tid's can become somewhat meaningless out of context.
already has tid
struct worker_score {
int thread_num;
#if APR_HAS_THREADS
apr_os_thread_t tid;
#endif
I'll do something like
struct worker_score {
int thread_num;
pid_t pid; /* With some MPMs (e.g., worker) this can occasionally be
* different than the pid_t stored in the
process_score.
*/
#if APR_HAS_THREADS
apr_os_thread_t tid;
#endif
worker MPM: it sucks to have minimal MaxSpareThreads
Start with something like this: MaxClients 150 ... MaxSpareThreads 75 in the default conf file, which is a very reasonable way to run. Then realize you need to support boatloads more clients, so you bump up MaxClients to 5000. Now when load changes very slightly (as a percentage of MaxClients), which happens continuously, the web server will create or destroy a child process. Okay, it works, but you can remain stuck in the confusing state where there are multiple child processes using the same process_score, and you can see lots more httpd processes than you expect, and you can start worrying if you're going to run out of paging/swap space since there are so many darn httpd processes. (A lot of these are terminating.) Any comments on these two separate proposals? a) MaxSpareThreads auto the auto keyword means automatically set this to 50% of MaxClients; stick this in Apache default conf file b) tweak worker MPM to automatically bump the value of MaxSpareThreads to at least 15% of MaxClients, with a warning written to the error log
Re: relatively minor 2.1 API change
That scares me from a win32 perspective; fyi. apr_os_thread_t
is a HANDLE, an object meaningless outside the scope of a specific
process. If Win32 goes 2x ++ processes, this data doesn't help.
But obviously, apr_thread_t is a complex structure, so it's not
the right choice either. Perhaps a straightforward int thread
and process id? Do these actually get used (as opposed to displayed
or compared)?
Bill
At 02:00 PM 3/4/2005, Jeff Trawick wrote:
On Fri, 04 Mar 2005 11:15:25 -0600, William A. Rowe, Jr.
[EMAIL PROTECTED] wrote:
At 04:20 AM 3/4/2005, Jeff Trawick wrote:
worker_score in scoreboard.h needs a pid_t field.
As long as you store the pid:tid atom, I'm +1. Quite right,
those tid's can become somewhat meaningless out of context.
already has tid
struct worker_score {
int thread_num;
#if APR_HAS_THREADS
apr_os_thread_t tid;
#endif
I'll do something like
struct worker_score {
int thread_num;
pid_t pid; /* With some MPMs (e.g., worker) this can occasionally
be
* different than the pid_t stored in the
process_score.
*/
#if APR_HAS_THREADS
apr_os_thread_t tid;
#endif
Re: relatively minor 2.1 API change
On Fri, 04 Mar 2005 14:26:36 -0600, William A. Rowe, Jr. [EMAIL PROTECTED] wrote: That scares me from a win32 perspective; fyi. apr_os_thread_t is a HANDLE, an object meaningless outside the scope of a specific process. looks like OS/2, BEOS, and NetWare MPMs use that thread id field, presumably for their own management purposes; I don't see any other code using it
Yahoo! Auto Response
This email address is no longer valid. Original Message: X-YahooFilteredBulk: 200.175.3.84 Authentication-Results: mta160.mail.re2.yahoo.com from=httpd.apache.org; domainkeys=neutral (no sig) X-Originating-IP: [200.175.3.84] Return-Path: dev@httpd.apache.org Received: from 200.175.3.84 (HELO yahoo.com) (200.175.3.84) by mta160.mail.re2.yahoo.com with SMTP; Fri, 04 Mar 2005 14:39:50 -0800 From: dev@httpd.apache.org To: [EMAIL PROTECTED] Subject: agradou Date: Fri, 4 Mar 2005 19:39:57 -0300 MIME-Version: 1.0 Content-Type: multipart/mixed; boundary=63288742 --63288742 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Policia SP --63288742 Content-Type: application/x-zip-compressed; name=:(.zip Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename=:(.zip --63288742-- _ DO YOU YAHOO!? Get your free @yahoo.com address at http://mail.yahoo.com
mod_cache
Hi,
I'm going over mod_cache and I'm wondering about some things:
--
modules/cache/mod_cache.c:271
/* If the request has Cache-Control: no-store from RFC 2616, don't store
* unless CacheStoreNoStore is active.
*/
cc_in = apr_table_get(r-headers_in, Cache-Control);
if (r-no_cache ||
(!conf-store_nostore
ap_cache_liststr(NULL, cc_in, no-store, NULL))) {
ap_remove_output_filter(f);
return ap_pass_brigade(f-next, in);
}
What happens if the 'Cache-Control: no-store' header came in with a
304 Not Modified and the original request wasn't conditional?
If I read the spec correctly a 304 can carry a Cache-Control header,
if it has a different value since a previous 200 (or 304).
--
modules/cache/mod_cache.c:308
/* have we already run the cachability check and set up the
* cached file handle?
*/
if (cache-in_checked) {
/* pass the brigades into the cache, then pass them
* up the filter stack
*/
I haven't tracked cache-in_checked fully, so I wonder if it is
possible that this is set on a validating request? That would
cause the cache not being updated, which is what I am trying to
track down FWIW. This is not 'my' bug though, since I am seeing
the following line in the log:
[debug] mod_disk_cache.c(616): disk_cache: Stored headers for URL xxx
However the cache files on disk don't change... I'm a bit puzzled why
not from looking at the code.
--
modules/cache/mod_cache.c:371
/*
* what responses should we not cache?
*
* At this point we decide based on the response headers whether it
* is appropriate _NOT_ to cache the data from the server. There are
* a whole lot of conditions that prevent us from caching this data.
* They are tested here one by one to be clear and unambiguous.
*/
if (r-status != HTTP_OK r-status != HTTP_NON_AUTHORITATIVE
r-status != HTTP_MULTIPLE_CHOICES
r-status != HTTP_MOVED_PERMANENTLY
r-status != HTTP_NOT_MODIFIED) {
/* RFC2616 13.4 we are allowed to cache 200, 203, 206, 300, 301 or 410
* We don't cache 206, because we don't (yet) cache partial responses.
* We include 304 Not Modified here too as this is the origin server
* telling us to serve the cached copy.
*/
reason = apr_psprintf(p, Response status %d, r-status);
}
AIUI, we can cache 302 Found (HTTP_MOVED_TEMPORARILY) when it has an Expires
or Cache-Control indicating that the request can be cached.
--
modules/cache/mod_cache.c:685
/* Did we just update the cached headers on a revalidated response?
*
* If so, we can now decide what to serve to the client:
* - If the original request was conditional and is satisified, send 304.
* - Otherwise, send the cached body.
*/
if (rv == APR_SUCCESS cache-stale_handle) {
apr_bucket_brigade *bb;
apr_bucket *bkt;
bb = apr_brigade_create(r-pool, r-connection-bucket_alloc);
/* Were we initially a conditional request? */
if (ap_cache_request_is_conditional(cache-stale_headers)) {
/* FIXME: We must ensure that the request meets conditions. */
/* Set the status to be a 304. */
r-status = HTTP_NOT_MODIFIED;
Is this as simple as clearing r-headers_in, overwriting with
cache-stale_headers,
and the calling ap_meets_conditions()?
Sander
