Re: authz: file-group ugliness
Explain this a little further because I am a little confused. What do you intend to happen when a directive like: require group ldap:foo dbm:bar bash is issued? The problem here is the confusion as to which module is handling 'group'. In order for this to work, every authorization type needs to be unique which probably means that they need to be prefixed with the authorization handler name require file-group somefilegroup require ldap-group cn=someldapgroup,o=whatever require dbm-group somedbmgroup Then as we discussed a few weeks back, Satisfy would have to be refactored to deal with authorization types rather than just the basic access control. Or am I missing something?? Brad >>> On 10/25/2005 at 9:47:31 am, in message <[EMAIL PROTECTED]>, [EMAIL PROTECTED] wrote: > > Or not... why not > >require group ldap:foo dbm:bar bash > > where bash would be a match against any provider, while foo would be > specific > to ldap, and bar would be specific to dbm?
Re: authz: file-group ugliness
Dirk-Willem van Gulik wrote: AuthOrder user group dbm-group which specifies an order of authz checks, and makes the last one 'authoritative' in terms of the old logic. Of course that still leaves file-group looking lonely. Maybe what that wants is a provider from authz_[file|dbm|dbd|ldap|etc] ? Or go back to this naming concept floating at one point: require group ldap:foo which solves this class of problems (but kills the failover part; i.e. getting a group check done in ldap if possible; but fall trough to htpasswd if all is down). Or not... why not require group ldap:foo dbm:bar bash where bash would be a match against any provider, while foo would be specific to ldap, and bar would be specific to dbm?
Re: authz: file-group ugliness
Dirk-Willem van Gulik said: > Or go back to this naming concept floating at one point: > > require group ldap:foo > > which solves this class of problems (but kills the failover part; i.e. > getting a group check done in ldap if possible; but fall trough to > htpasswd if all is down). This should work if memory serves: require ldap:foo require file:foo satisfy any Regards, Graham --
Re: authz: file-group ugliness
> AuthOrder user group dbm-group which specifies an order of authz checks, > and makes the last one 'authoritative' in terms of the old logic. > > Of course that still leaves file-group looking lonely. Maybe what that > wants is a provider from authz_[file|dbm|dbd|ldap|etc] ? Or go back to this naming concept floating at one point: require group ldap:foo which solves this class of problems (but kills the failover part; i.e. getting a group check done in ldap if possible; but fall trough to htpasswd if all is down). Dw
Re: authz: file-group ugliness
On Tuesday 25 October 2005 00:29, you wrote: >This would be OK except that there is a bigger problem that I looked > into trying to fix at one point but never completed it. The problem is > the duplication of authorization types. Currently we have both > mod_authz_groupfile and mod_authz_dbm implementing the types "group" and > "file-group". This causes a problem because if both of these modules > are loaded and the configuration contains the directive: > > require group foo > or > require file-group > > which authorization module handles it? Well it seems to be completely > dependant on load order and/or the use of the directives > AuthzXXXAuthoritative. In addition to implementing an optional function > in mod_authz_owner to get the owner id, all authorization types should > probably be renamed to be unique. > > group - mod_authz_groupfile > dbm-group - mod_authz_dbm > dbd-group - mod_authz_dbd > ldap-group - mod_authnz_ldap (already done) > etc... > > thoughts on this...? Well, AFAICS that ambiguity only really kicks in if you have both an AuthGroupFile and an AuthDBMGroupFile, which is something that would be equally(?) problematic in 1.x/2.0. Ugly - yes. Totally broken - no. Unless I'm missing something? That still leaves an aura of ambiguity hanging around AuthAuthoritative. Perhaps a better solution would be to replace that with something like AuthOrder user group dbm-group which specifies an order of authz checks, and makes the last one 'authoritative' in terms of the old logic. Of course that still leaves file-group looking lonely. Maybe what that wants is a provider from authz_[file|dbm|dbd|ldap|etc] ? -- Nick Kew
Re: authz: file-group ugliness
This would be OK except that there is a bigger problem that I looked into trying to fix at one point but never completed it. The problem is the duplication of authorization types. Currently we have both mod_authz_groupfile and mod_authz_dbm implementing the types "group" and "file-group". This causes a problem because if both of these modules are loaded and the configuration contains the directive: require group foo or require file-group which authorization module handles it? Well it seems to be completely dependant on load order and/or the use of the directives AuthzXXXAuthoritative. In addition to implementing an optional function in mod_authz_owner to get the owner id, all authorization types should probably be renamed to be unique. group - mod_authz_groupfile dbm-group - mod_authz_dbm dbd-group - mod_authz_dbd ldap-group - mod_authnz_ldap (already done) etc... thoughts on this...? Brad >>> On 10/24/2005 at 4:08:39 pm, in message <[EMAIL PROTECTED]>, [EMAIL PROTECTED] wrote: > I've just looked at authz. > > There's an IMO ugly hack whereby every authz provider has to run after > authz_file and make a special case for file-group. It's repitition of > identical code, and breaks modularity. > > Wouldn't it be better for mod_authz_owner to be able to determine whether > file-group is satisfied before returning, instead of faffing about with Notes > and complicating the AuthAuthoritativeness logic? We could implement that > using a file-group optional hook in mod_authz_owner. The normal authz_FOO > modules can then implement the hook and properly preserve modularity. > > Any thoughts?
authz: file-group ugliness
I've just looked at authz. There's an IMO ugly hack whereby every authz provider has to run after authz_file and make a special case for file-group. It's repitition of identical code, and breaks modularity. Wouldn't it be better for mod_authz_owner to be able to determine whether file-group is satisfied before returning, instead of faffing about with Notes and complicating the AuthAuthoritativeness logic? We could implement that using a file-group optional hook in mod_authz_owner. The normal authz_FOO modules can then implement the hook and properly preserve modularity. Any thoughts? -- Nick Kew
