On Fri, Apr 15, 2005 at 06:12:33PM +0200, Jan Kopriva wrote:
> Hi again,
> 
> I looked again to the cfs.cc and performed some tests. I realized that
> 2KB buffer is actually enough to hold 20 ACL entries. Also if you
> create an ACL longer than 20 entries it is rejected by Vice and not by
> the kernel as I previously thought. The thing is that Vice has
> AL_MAXEXTENTRIES constant set to 20. This enforces the limit.

Correct, the ACLs are stored at the end of the directory vnodes. The
amount of space is quite limited (I think about 400 bytes). In this
space we store the AL_AccessList structure, which currently uses 20
bytes + AL_MAXENTRIES * 8 bytes = 180 bytes. I guess there is space to
store more ACLs, but a better solution is probably to export group
management functionality to the end user through the auth2 daemon
(and au on the client).

Right now the user/group database contains a 'group owner' who is
supposed to be a user that is allowed to add/remove members. If users
could create and manage their own groups remotely they probably wouldn't
need all that many ACLs.

> The user after creating more than 20 entries in the ACL obtains 
> following message:
> .: Invalid argument

Just looked at what the server does, it returns E2BIG, I wonder where
that is mapped to the non-descriptive EINVAL error.

> which does not say anything about the problem. So, I have made a patch 
> to cfs.cc that forces the cfs process to tell the user that he/she
> execeeds the limit of an ACL and that also after each ACL listing,
> provides its length.
> 
> It counts with AL_MAXEXTENTRIES constant, thus if anyone changes it at 
> Vice source, he should keep in mind the Venus limit (1000 entries) and
> kernel 2KB limit. Patch does not check if AL_MAXEXTENTRIES follows the
> limitations above.

Which is why I think it is probably better to get the correct error code
propagated back from the server to cfs so that it can give a useful
response without having to rely on a hardcoded value.

Jan