* modules/aaa/mod_authz_owner.h: Add header file with optional hook declaration for "authz_owner_get_file_group". * modules/aaa/mod_authz_dbm.c, modules/aaa/mod_authz_groupfile.c: Use the header to pick up the above declaration; retrieve the optional function in a hook; use a static variable to store the function pointer.

cppCheck: kill a unread variable warning

Add lots of unique tags to error log messages

Allow authz providers to check args while reading the config and allow them to cache parsed args. Use this to check that argument to 'all' provider is 'granted' or 'denied'.

The approach for allowing authorization by user or IP introduced in r956387, etc. causes problems because the authentication module calls note_*_auth_failure if authentication fails. This is inappropriate if access is later allowed because of the IP. So, instead of calling the auth_checker hook even if authentication failed, we introduce a new access_checker_ex hook that runs between the access_checker and the check_user_id hooks. If an access_checker_ex functions returns OK, the request will be allowed without authentication. To make use of this, change mod_authz_core to walk the require blocks in the access_checker_ex phase and deny/allow the request if the authz result does not depend on an authenticated user. To distinguish a real AUTHZ_DENIED from an authz provider from an authz provider needing an authenticated user, the latter must return the new AUTHZ_DENIED_NO_USER code.

Use the new APLOG_USE_MODULE/AP_DECLARE_MODULE macros everywhere to take advantage of per-module loglevels

remove unused AUTHZ_GROUP_NOTE define

Prior to authn/z refactoring in r368027, if authorization Require directives had no matching AuthType and associated authentication directives, requests would generally fall through in the check_user_id hook to mod_authn_default.c's authentication_no_user() handler, which returned DECLINED if ap_auth_type() was not set. The ap_process_request_internal() function in request.c would handle this case by logging an "AuthType not set!" error and returning HTTP_INTERNAL_SERVER_ERROR. The refactoring removes this error handling in request.c, so individual modules will need to test for a lack of authentication, as necessary. Since some modules such as mod_authz_host.c support Require directives that do not need any authentication, the mod_authn_default.c handler no longer returns DECLINED if ap_auth_type() is not set. (Also, mod_authn_default can be compiled out with --disable-authn-default, so it can't be relied upon to exist.) Since r->user may now be NULL, individual handlers must test for that case when necessary. Otherwise, most Require directives in the absence of AuthType directives cause handlers to crash while performing strcmp() and friends on a NULL r->user value. NOTE: I can't test mod_authnz_ldap.c myself, so I'm not sure if it needs similar fixes. On the one hand, a NULL r->user in the authz handlers always generates a log message. However, it appears that authn_ldap_build_filter() will sometimes then be called, perform no action, which may result in a possibly uninitialized filtbuf buffer being passed to util_ldap_cache_getuserdn(). I don't know if that could cause problems in the LDAP cache code. If someone familiar with LDAP authz could take a look, that would be much appreciated.

Convert common provider version strings ("0") to AUTHN/Z_PROVIDER_VERSION macros defined in mod_auth.h.

Avoid calling access control hooks for internal requests with configurations which match those of the initial request. Revert to the original behaviour (call access control hooks for internal requests with URIs different from the initial request) if any access control hooks or providers are not registered as permitting this optimization. Introduce wrappers for access control hook and provider registration which can accept additional mode and flag data. The configuration walk optimizations were originally proposed a while ago (see http://marc.info/?l=apache-httpd-dev&m=116536713506234&w=2); they have been used since then in production systems and appear to be stable and effective. They permit certain combinations of modules and clients to function efficiently, especially when a deeply recursive series of internal requests, such as those generated by certain WebDAV requests, are all subject to the identical authentication and authorization directives. The major change from the original proposal is a cleaner mechanism for detecting modules which may expect the old behaviour. This has been tested successfully with Subversion's mod_authz_svn, which specifically requires the old behaviour when performing path-based authorization based against its own private access control configuration files.

update license header text

Update the copyright year in all .c, .h and .xml files

remove the unused per-dir-config structure.

Authz refactoring Merge from branches/authz-dev Basically here is a list of what has been done: - Convert all of the authz modules from hook based to provider based - Remove the ap_requires field from the core_dir_config structure - Remove the function ap_requires() since its functionality is no longer supported or necessary in the refactoring - Remove the calls to ap_some_auth_required() in the core request handling to allow the hooks to be called in all cases. - Add the new module mod_authz_core which will act as the authorization provider vector and contain common authz directives such as 'Require', 'Reject' and '<RequireAlias>' - Add the new module mod_authn_core which will contain common authentication directives such as 'AuthType', 'AuthName' and '<AuthnProviderAlias>' - Move the check for METHOD_MASK out of the authz providers and into the authz_core provider vector - Define the status codes that can be returned by the authz providers as AUTHZ_DENIED, AUTHZ_GRANTED and AUTHZ_GENERAL_ERROR - Remove the 'Satisfy' directive - Implement the '<RequireAll>', '<RequireOne>' block directives to handle the 'and' and 'or' logic for authorization. - Remove the 'AuthzXXXAuthoritative' directives from all of the authz providers - Implement the 'Reject' directive that will deny authorization if the argument is true - Fold the 'Reject' directive into the '<RequireAll>', '<RequireOne>' logic - Reimplement the host based authorization functionality provided by 'allow', 'deny' and 'order' as authz providers - Remove the 'allow', 'deny' and 'order' directives - Merge mod_authn_alias into mod_authn_core - Add '<RequireAlias>' functionality which is similar to '<AuthnProviderAlias>' but specific to authorization aliasing - Remove all of the references to the 'authzxxxAuthoritative' directives from the documentation - Remove the 'Satisfy' directive from the documentation - Remove 'Allow', 'Deny', 'Order' directives from the documentation - Document '<RequireAll>', '<RequireOne>', 'Reject' directives - Reimplement the APIs ap_auth_type(), ap_auth_name() as optional functions and move the actual implementation into mod_authn_core - Reimplement the API ap_some_auth_required() as an optional function and move the actual implementation into mod_authz_core Major Changes: - Added the directives <RequireAll>, <RequireOne>, <RequireAlias>, Reject - Expanded the functionality of the directive 'Require' to handle all authorization and access control - Added the new authz providers 'env', 'ip', 'host', 'all' to handle host-based access control - Removed the directives 'Allow', 'Deny', 'Order', 'Satisfy', 'AuthzXXXAuthoritative' - Removed the ap_require() API - Moved the directives 'AuthType', 'AuthName' out of mod_core and into mod_authn_core - Moved the directive 'Require' out of mod_core and into mod_authz_core - Merged mod_authn_alias into mod_authn_core - Renamed mod_authz_dbm authz providers from 'group' and 'file-group' to 'dbm-group' and 'dbm-file-group' Benefits: - All authorization and access control is now handle through two directives, 'Require' and 'Reject' - Authorization has been expanded to allow for complex 'AND/OR' control logic through the directives '<RequireAll>' and '<RequireOne>' - Configuration is now much simpler and consistent across the board - Other modules like mod_ssl and mod_proxy should be able to plug into and take advantage of the same provider based authorization mechanism by implementing their own providers Issues: - Backwards compatibility between 2.2 and 2.3 configurations will be broken in the area of authorization and access control due to the fact that the directives 'allow', 'deny', 'order' and 'satisfy' have been removed. When moving from 2.2 to 2.3 these directives will have to be changed to 'Require all granted', 'Require all denied' or some variation of the authz host-based providers. - Existing third party authorization modules will have to adapt to the new structure.

No functional Change: Removing trailing whitespace. This also means that "blank" lines consisting of just spaces or tabs are now really blank lines

Update copyright year to 2005 and standardize on current copyright owner line.

fix name of The Apache Software Foundation

fix copyright dates according to the first check in

apply Apache License, Version 2.0

update license to 2004.

finished that boring job: update license to 2003. Happy New Year! ;-))

as announced and with no objections: mod_authz_owner: forward port of require file-owner/file-group functionality The goal of the module is to do all the neccessary file system work to figure out username and groupname. "Require file-owner" is completely resolved within the module. "file-group" is only determined there and the groupname will be extracted from the stat call and stored within the r->notes. Done that, the module will decline, so that the group database modules (mod_authz_groupfile, mod_authz_dbm) can verify the groupname with their lists. Thus every group module that supports the file-group requirement must be hooked after mod_authz_owner. They have to recognize "file-group" and read the groupname from r->notes. (If there's no name stored, the modules should ignore the file-group requirement). The backstopper module will do its work in worst case. not solved yet: - the module doesn't work as one could expect if the file doesn't exist in the first request round (consider MultiViews) (the 1.3 version has the same problem). I played around with some subrequest techniques, but got no helpful result. Is there any magic to recognize the actual resulting filename (if there is)?