Re: Announcing Access Authorization Documentation

Subject: Re: Announcing Access Authorization Documentation
Content-Length: 4198
Status: RO

   Hello Christopher,

First, thank you for going through the documentation and for your reply!

>   I've read through your documentation and it looks good except for
> 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 to allow for many
> 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 as
>     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.

I couldn't agree with you more. I will add this to the final version,
but I think I put the template first:


because it seems most logical, doesn't it?

>   Also, could you clarify some thing for me?  Regarding the <template>
> 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:

The <template> in ACL file in each directory matches *only* files 
in *that* directory. The reasons are the following:

	* if I had a file /a/b/c, and the ACL entry in the directory /a
	  would restrict access to c somehow, but this restriction wouldn't
	  be in the ACL in directory /a/b (because it would be redundant),

		* first of all, we would always have to go through
		  every ACL file in the way down the hierarchy
		  (a performance problem)

		* but also, and more importantly, someone on the
		  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)

	      [ * Note also, that soft links still pose a problem,
		  as described in:

		  and are the reason for "fork" rule (or servers on
		  multiple ports). ]

All the ACL information could be put to rule file, but this would make
the rule file too big and slow down servers unnecessarily. Therefore
it is better to distribute ALC information into each directory.

On the other hand, we could manage without the "protect" rule, but
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:


Someone might say: why not treat a file not in ACL as public, but
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?

The semantics of the "protect" rule is therefore just to inform the
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.

Note: in my opinion this should go the other way around: Access Authorization
      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.

-- Salut, Ari --
                     \\\\Ari Luotonen//////
                      \\\\WWW Person//////