GNU Info

(cvs.info)File permissions

---

Next: Windows permissions Prev: Repository files Up: Repository storage

---

Enter node , (file) or (file)node

File permissions
----------------

   All `,v' files are created read-only, and you should not change the
permission of those files.  The directories inside the repository
should be writable by the persons that have permission to modify the
files in each directory.  This normally means that you must create a
UNIX group (see group(5)) consisting of the persons that are to edit
the files in a project, and set up the repository so that it is that
group that owns the directory.

   This means that you can only control access to files on a
per-directory basis.

   Note that users must also have write access to check out files,
because CVS needs to create lock files (Note: Concurrency).

   Also note that users must have write access to the
`CVSROOT/val-tags' file.  CVS uses it to keep track of what tags are
valid tag names (it is sometimes updated when tags are used, as well as
when they are created).

   Each RCS file will be owned by the user who last checked it in.
This has little significance; what really matters is who owns the
directories.

   CVS tries to set up reasonable file permissions for new directories
that are added inside the tree, but you must fix the permissions
manually when a new directory should have different permissions than its
parent directory.  If you set the `CVSUMASK' environment variable that
will control the file permissions which CVS uses in creating directories
and/or files in the repository.  `CVSUMASK' does not affect the file
permissions in the working directory; such files have the permissions
which are typical for newly created files, except that sometimes CVS
creates them read-only (see the sections on watches, Note: Setting a
watch; -r, Note: Global options; or `CVSREAD', Note: Environment
variables).

   Note that using the client/server CVS (Note: Remote repositories),
there is no good way to set `CVSUMASK'; the setting on the client
machine has no effect.  If you are connecting with `rsh', you can set
`CVSUMASK' in `.bashrc' or `.cshrc', as described in the documentation
for your operating system.  This behavior might change in future
versions of CVS; do not rely on the setting of `CVSUMASK' on the client
having no effect.

   Using pserver, you will generally need stricter permissions on the
CVSROOT directory and directories above it in the tree; see Note:
Password authentication security.

   Some operating systems have features which allow a particular
program to run with the ability to perform operations which the caller
of the program could not.  For example, the set user ID (setuid) or set
group ID (setgid) features of unix or the installed image feature of
VMS.  CVS was not written to use such features and therefore attempting
to install CVS in this fashion will provide protection against only
accidental lapses; anyone who is trying to circumvent the measure will
be able to do so, and depending on how you have set it up may gain
access to more than just CVS.  You may wish to instead consider
pserver.  It shares some of the same attributes, in terms of possibly
providing a false sense of security or opening security holes wider
than the ones you are trying to fix, so read the documentation on
pserver security carefully if you are considering this option (Note:
Password authentication security).