Shell Accounts and Distributed Version Control
One of the commonly cited criticisms of distributed version control systems is the lack of a central repository which contains the canonical state of the code. In reality creating such a repository is as simple as anointing one of the repositories as canonical. On the other hand, once such a repository is set up, the problem of access control raises it's ugly head.
Subversion + Access Control
Subversion is the de facto open source centralized version control system and it's use of WebDAV allows it to piggy back on all of the authentication and authorization schemes available to web-servers. In practice this often means that users are managed using a htpasswd file. There are a number of tools that allow one to manage htpasswd files ranging from the TracAccountManager to htpasswd itself.
Thus, adding or removing a user can be as simple as adding or removing a line from a single configuration file.
Handing Out Shell Accounts
The simplest way to share write access to DVCS repositories is to give each user a shell account on the machine that hosts the repository. This allows each user to push and pull changes to the repository using ssh. This strategy has the very nice property that it allows one to access and update a tree over the network without actually making the tree public. The same effect can be achieved using Subversion by requiring commit rights to read the repository, but that is not the default configuration.
It may concern some people to be handing out shell accounts simply to allow write access to a repository. One of the alternatives, inspired by the python development practice is to have a single contributor account on the machine and to use ssh authentication in place of a password. Using ssh authentication allows several contributors to share the same shell account, without being able to easily subvert it. Interestingly, the python.org developers use Subversion.
Other Alternatives
At work, my team has no less than three separate shared file systems. While not particularly feasible for collaboration over the Internet, for a team united behind a firewall, placing the repository on a shared drive is an extremely simple option.