GNU Info

(cvsbook.info)Anonymous Access

---

Next: Repository Structure Prev: The Password-Authenticating Server Up: Repository Administration

---

Enter node , (file) or (file)node

Anonymous Access
================

So far we've only seen how to use the password-authenticating server to
grant normal full access to the repository (although admittedly one can
restrict that access through carefully arranged Unix file permissions).
Turning this into anonymous, read-only access is a simple step: You just
have to add a new file, or possibly two, in CVSROOT/.  The files' names
are `readers' and `writers' - the former containing a list of usernames
who can only read the repository, the latter users who can read and
write.

If you list a username in CVSROOT/readers, that user will have only read
access to all projects in the repository.  If you list a username in
CVSROOT/writers, that user will have write access, and every pserver
user not listed in writers will have read-only access (that is, if the
writers file exists at all, it implies read-only access for all those
not listed in it).  If the same username is listed in both files, CVS
resolves the conflict in the more conservative way: the user will have
read-only access.

The format of the files is very simple: one user per line (don't forget
to put a newline after the last user).  Here is a sample readers file:

     anonymous
     splotnik
     guest
     jbrowse

Note that the files apply to CVS usernames, not system usernames.  If
you use user aliasing in the CVSROOT/passwd file (putting a system
username after a second colon), the leftmost username is the one to list
in a readers or writers file.

Just to be painfully accurate about it, here is a formal description of
the server's behavior in deciding whether to grant read-only or
read-write access:

If a readers file exists and this user is listed in it, then she gets
read-only access.  If a writers file exists and this user is not listed
in it, then she also gets read-only access (this is true even if a
readers file exists but that person is not listed there).  If that
person is listed in both, she gets read-only access.  In all other
cases, that person gets full read-write access.

Thus, a typical repository with anonymous CVS access has this (or
something like it) in CVSROOT/passwd

     anonymous:XR4EZcEs0szik

this (or something like it) in /etc/passwd

     anonymous:!:1729:105:Anonymous CVS User:/usr/local/newrepos:/bin/false

and this in CVSROOT/readers:

     anonymous

And, of course, the aforementioned setup in /etc/services and
/etc/inetd.conf.  That's all there is to it!

Note that some older Unix systems don't support usernames longer than
eight characters.  One way to get around this would be to call the user
`anon' instead of `anonymous' in CVSROOT/passwd and in the system
files, because people often assume that anon is short for anonymous
anyway.  But it might be better to put something like this into the
CVSROOT/passwd file

     anonymous:XR4EZcEs0szik:cvsanon

(and then of course use `cvsanon' in the system files).  That way,
you'd be able to publish a repository address that uses `anonymous',
which is more or less standard now.  People accessing the repository
with

     cvs -d :pserver:anonymous@cvs.foobar.com:/usr/local/newrepos (etc...)

would actually run on the server as cvsanon (or whatever).  But they
wouldn't need to know or care about how things are set up on the server
side - they'd only see the published address.