Hi,
This is the second part of authentication and authorization.
[the exact same thing regarding authentication was discussed
by the svn team earler and is in 'notes/auth_proposal.txt']
Authorization is quite an issue. Most cvs repost admins will
know about the cvs_acls.pl script that is hooked to commitinfo.
This allows you to restrict commit access on paths in the repos.
Ofcourse this system is limited. [sidenote: Greg pointed out
that cvs_acls.pl can easily be relaced with apache authorization]
Other access restrictions are enforced by filesystem permissions.
With subversion we have a chance to get this stuff 'right'. But
that isn't easy.
The first thought that came up was to add the authorization to the
network layer, like the authentication. This is limited though
and puts you in a corner when it comes to implementing. Also,
there would be much duplication, since each ra layer has to
implement it, to be effective. If multiple systems would use
different config layouts, there would be administrative duplication
aswell. This is ofcourse something we don't want, so lets throw
this idea out.
On to the next idea. ACLs in the repository. This seems like
a good idea. It has some issues, but these should be solvable
(be it through documentation or code). To implement acls in
the repos, we could use the auth_hook idea in
notes/auth_proposals.txt. We can feed it the acl checking hook
once that is implemented.
How would the acls look like?
typedef struct svn_acl_t svn_acl_t;
struct svn_acl_t
{
svn_acl_t *next;
const char *user; /* Or maybe a user id? */
const char *group; /* Or maybe a group id? */
apr_uint32_t access_flags;
};
If both user and group are NULL, the acl is the ALL
acl. The user and group field can't both be valid.
Therefore, one should always be NULL if the other is
set.
access_flags is a bitfield:
#define ACL_Fxxxx (1 << 0)
#define ACL_Fxxxx (1 << 1)
etc.
#define ACL_FALL (all of the above added up)
These have to match the actions a user can perform.
I would like these to match the command line more than
the internals, so it is clearer to an admin (and to
people not as familiar with the svn internals. Also,
we don't know what will change in the fs layer when
we present a database backed fs. So, having flags for
'checkout, update, commit, rm, add, mv, import, annotate'
seems like a good idea. I don't know if this can be
implemented, but that is for another day :)
Obviously we also need a flag for acl setting.
ACLs are inherited. If the parent has an acl and a child
has not, or when the check fails to match all acls in the
child, the check is performed on the parent instead.
Order of acls should not matter. If an item has an acl
chain like this:
next -> next -> NULL
striker commiters
ACL_FCHECKOUT| ACL_FALL
ACL_FUPDATE
And striker would be in the group commiters, then he should
only have checkout and update privilidges on this item.
If the first acl and the second were reversed the result
should be the same.
If a user 'gwappo' would have been checked against the above
chain (he isn't in commiters) the check would have to fall
back to the parent acl chain, because there is no match in this
one.
ACLs should not be versioned (ie acl changes do not have to
be tracked), they do apply to a single version of an item and
all next versions.
When an acl is set/changed on an item later on, this should
optionally propagate back to earlier revisions. Therefore, it
seems logical to put acl chains in by reference, so only one
actual acl chain needs updating. Ofcourse this brings up a
problem. If in the history of the item the item was branched,
the acl applying should stop and ask the admin what to do:
1 - continue to apply the new acl onto earlier revisions
thereby influencing privilidges in the other branch aswell;
2 - stop applying the new acl at this branch, only the current
branch gets the new acl. In the implementation this would
mean copying the new acl and putting that on the first
revision of the item in the current branch.
Ok, 2AM here, calling it a nightzzzz...
Questions/remarks in my head:
- Where should ACLs be stored?
- We should have a svn acl command.
- How do we do the user -> group mapping?
Sander
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Sat Oct 21 14:36:39 2006