First, thank you for going through the documentation and for your reply!
> I've read through your documentation and it looks good except for
I couldn't agree with you more. I will add this to the final version,
template:method,method,...:group,user,group,...
because it seems most logical, doesn't it?
> Also, could you clarify some thing for me? Regarding the <template>
The <template> in ACL file in each directory matches *only* files
* if I had a file /a/b/c, and the ACL entry in the directory /a
* first of all,
* but also, and more importantly, someone on the
[ * Note also, that soft links still pose a problem,
http://info.cern.ch/hypertext/WWW/AccessAuthorization/LinkDiscussion.html
and are the reason for "fork" rule (or servers on
All the ACL information could be put to rule file, but this would make
On the other hand, we could manage without the "protect" rule, but
get:*:anybody
Someone might say: why not treat a file not in ACL as public, but
The semantics of the "protect" rule is therefore just to inform the
Note: in my opinion this should go the other way around: Access Authorization
-- Salut, Ari --
> one issue: there is no provision for controlling access *per method*.
> Once we have implemented the PUT and POST methods of HTTP, I expect
> it will be quite common for a webmaster to wish
> readers relative to the number of writers for a particular resource.
> I suggest that you add a <methods> field to the .www_acl file, such
>
> method,method,...:template: group,user,group,...
>
> or some other syntax. Alternatively, you could specify the methods in
> the rule file, but the access list seems a better place to me.
but I think I put the template first:
> specified in the protect rule of the rule file and also in each entry of
> the access control list: Does this <template> refer only to files or can
> it be a subdirectory - the latter indicating that the entire hierarchy
> is to be accessible only to those in the corresponding user/group list?
> Here are the pertinent references:
in *that* directory. The reasons are the following:
would restrict access to c somehow, but this restriction wouldn't
be in the ACL in directory /a/b (because it would be redundant),
(a performance problem)
same machine could make a soft link to directory b
so that he could access file c for example like:
/foo/bar/b/c and this way ACL file in directory /a
would be never consulted (a security hole)
as described in:
multiple ports). ]
the rule file too big and slow down servers unnecessarily. Therefore
it is better to distribute ALC information into each directory.
in that case we would also have to have an entry for public file in
the ACL, and therefore each site starting to use the new httpd would
have to make dozens of these dummy ACL files containing something like:
this would be a BIG security risk, because somebody might forget to
put an entry for a REALLY secret file, and then it would be treated
as public. I rather have it like it is: if there is no entry in ACL,
access is 403 Forbidden, meaning that giving access authorization
does not help. Anybody oppose to that?
server, that the ACL file should be consulted. Without that directive
the server will bypass Access Authorization, and work exactly like all
the current httpds do. Clean.
should normally be always on, and there should be some special rule,
something like "bypass" that would explicitly tell that files in these
directories are public. This way forgetting to "protect" something
wouldn't result in files becoming exposed, but rather inaccessible to
everybody. However, I cannot tamper with the semantics for "pass", and
I believe this "protect" thing will work well enough.
\\\\Ari Luotonen//////
\\\\WWW Person//////
\\\\\\/\\\\\//////
\\\\//\\\\//////
\\////\\//////
\/\/\/\/\/\/