httpd-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From André Malo>
Subject Re: Forward port Require file-owner/file-group; need review and help ;-)
Date Sat, 11 Jan 2003 00:47:49 GMT
* André Malo wrote:

> that functionality was not ported into 2.x yet.
> For summary look at the attachment, please ;-)
> I've created a module "mod_authz_owner", which basically ports the
> functionality, but with some enhancements. Both requirements should work on
> every system where APR_HAS_USER. (or at least throw an appropriate error
> message - think of the differences between Win9x, WinNT, 2k etc.)

hmm, I guess, you're all occupied. However, I think, I'll commit it within 
some days and we'll see further then?

[fullquote without attachments follows:]
> 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 ignore
> the file-group requirement). The backstopper module will do its work in
> worst case.
> However, there are some problems, that need help and further review:
> - is that note principle ok (in concept?) or is there a better way to
>   communicate?
> - I defined slightly different semantics of AuthzOwnerAuthoritative.
>   It acts as "file-owner" and "file-group" were defined in different
>   modules. So if set to On, only one of them will be recognized and if it
>   fails, a 401 response will happen. If Off, both may be recognized and the
>   best match will be done.
>   I'm not sure, whether this is good or bad, opinions are desired :)
> - the module doesn't work as one could expect if the file doesn't exist in
>   the first request round (consider MutliViews) (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? Or can we safely send OK if the file doesn't exist (instead of
>   401)?
> - generally - are there any style issues, I have violated? ;-)
> TIA, nd
If God intended people to be naked, they would be born that way.
  -- Oscar Wilde

View raw message