ACL implementation comments

[Alexey M. <al...@hs...>]

Hello,

I've started implementing ACLs.

The goals of implementation are rather strict and probably unusual,
and I'd very much like to keep it that way.  In short, I'm hooked on
one particular aspect of eXtreme Programming: Test First.

Everyone interested are encouraged to read

William C. Wake, "XP Explored":
http://users.vnet.net/wwake/xp/explored/XP-Explored.pdf

Ronald E. Jeffries, Ann Anderson and Chet Hendrickson, "XP Installed":
http://classes.seattleu.edu/computer_science/csse514/klawitter/pdf/xpinstalled.pdf


and follow the guidelines.  The ACL stuff is in the acl/ subdirectory.
Look especially at the check_acl.c and other check_*.c to get a clue
on what is the current functionality, and how do the tests look like.


As for the functional specification, you can take a look at the
current revision of /www/acl-rfc.txt from the project (soon to be
updated to Draft III).

As for the on-disk structures, I don't think that's important
currently.  It probably will be subject to discussion a couple of
weeks from now, when there will be a need to keep backwards
compatibility.  Anyway, the format is designed to be simple, and
simply extensible:

  branch-level ACLs are kept in `ACL' file in each directory.  File is
  of the following format: 

<space>filename\t	branch\t	username\t	rights...

  the leading <space> is exactly a means of extensibility.  When new
  kinds of records will be needed, we'll just use another character
  instead.  See the data-file format of djbdns.

I don't think there will be a strong need to create any indices over
that file (given that 95% of permissions will be handled by
directory-level ACLs), but if it'll ever be needed, we'll always be
able to do just that, with a lot of tests supporting that change.


To properly test user-level operations, we'll need to finally create
Autotest-based testsuite for the client binary (and its server
counterpart).  It is a nice task in itself (and I think that stock CVS
will gladly accept if it's going to be backported there), so if
somebody needs something to work on -- here it is.

A yet another "dynamic strings" structure is created in a form of
"stringbuf.h".  I don't think it will ever need a lot of
functionality, so don't bother extending it without a clear need (and
tests first, sure).


Comments?

--alexm