Frequently Asked Questions for cvsd
===================================

the latest version of this FAQ can be found at
http://ch.tudelft.nl/~arthur/cvsd/faq.html

In no particular order:
 1. How secure is cvsd?
 2. How does one use cvs over ssh?
 3. cvs checkout . fails
 4. setgid failed: Operation not permitted
 5. setgroups: Operation not permitted
 6. cvsd: no such user
 7. pam failed to release authenticator
 8. Is cvs required for running cvsd?
 9. What should I put in the chroot directory?
10. How can I run commands from loginfo/commitinfo/...?
11. How do I add extra debugging?
12. What about running cvs pserver as root?
13. How do I file a bug report?
14. Should I start the cvsd program as the cvsd user?
15. How about logging?
16. Why are tcp wrappers not working?
17. Why can't I combine some Listen options?
18. How do I enable syslog inside the chroot jail?
19. Interrupted system call
20. cannot create_adm_p /tmp/cvs-serv5153/... Permission denied
21. Will you implement a reload in the init script?
22. Will you pass -R (readonly) to cvs?

 1. How secure is cvsd?
    The only security cvsd adds to a cvs pserver is in the fact that
    possible exploits and misconfigurations in the server will most
    likely not result in the compromise of the machine (don't forget
    the disclaimer though). cvsd does not improve the inherent
    weaknesses of the pserver protocol such as cleartext passwords,
    use cvs over ssh for that.
 2. How does one use cvs over ssh?
    Not really anything to do with cvsd but here goes:
    % export CVS_RSH=ssh
    % cvs -d remotehost:repositorypath <whatever cvscommand>
    You need a ssh account on the remotehost and access to the
    repositorypath. This setup is particularly useful for secure
    authenticated development access, while cvsd is more useful for
    public read-only access.
 3. 'cvs -d ... checkout .' fails with something like "Assertion
    `*short_repos++ == '/'' failed." but other checkouts work fine,
    what's wrong?
    Older versions of cvs (at least 1.10.7 but 1.11.1p1 is fixed) have
    a bug where the repository is a direct descendant of the root
    directory. You should probably upgrade cvs on the server side.
 4. cvs login works but cvs checkout or other commands fail with
    "setgid failed: Operation not permitted"
    This can happen when you run cvsd as non-root (which is
    recommended) and didn't set up your repository passwd file
    (CVSROOT/passwd) correctly. The repository passwd files should
    contain mappings of cvs users to the user you specified in
    cvsd.conf. If no mapping is present cvs tries to become the
    "original" user and fail because it's not running as root. Your
    repository passwd files should look like:
    anonymous:XGPg1ub8xh70U:cvsd
    Another possibility is that your system uses something different
    for providing user information (nis/ldap/etc) and that your chroot
    passwd file (e.g. /var/lib/cvsd/etc/passwd) does not match the
    system passwd database (any more). This is especially important if
    your chroot jail is on an nfs filesystem.
    In this case it may be needed to rerun cvsd-buildroot and check
    it's output (and possibly the output of cvsd-buginfo) to see which
    users are missing.
 5. cvs login works but cvs checkout or other commands fail with
    "setgroups: Operation not permitted"
    Also see the previous question.
    Setgroups is called to change the supplemental groups the user is
    in. This can happen when /etc/groups exists inside the chroot jail
    and the cvsd user is member of some groups.
 6. cvs login works but cvs checkout or other commands fail with
    "cvsd: no such user" or "cvsd: no such system user"
    The cvs pserver maps users found in the repository passwd file
    (CVSROOT/passwd) to users in the system passwd file. Since cvs is
    running in a chroot environment the system passwd file is located
    in /var/lib/cvsd/etc/passwd (depending on what you set your
    RootJail to). If you set up user mappings correctly there should
    be a cvsd user in the passwd file.
    cvsd-buildroot checks the chroot jail's /etc/passwd file and adds
    users from the system /etc/passwd if needed (and generates
    warnings for missing users).
    If you need ldap or similar methods to provide user id information
    you need to set up the proper configuration inside the chroot
    jail.
 7. cvs commands fail with "unrecognized auth response from server:
    pam failed to release authenticator."
    Your repository is probably configured to use pam as an
    authentication mechanism. Edit your repository configuration file
    (CVSROOT/config) and set the following options:
    SystemAuth=no PamAuth=no
    If you really want to use PAM to do the authentication you should
    copy all needed PAM modules and configuration files into the
    chroot directory.
 8. Is cvs required for running cvsd?
    Yes. cvsd is just a wrapper for running cvs in pserver mode. It
    runs cvs in a chroot jail and possibly sets resource limitations.
    The complete protocol handling is done by cvs although there are
    some plans to do some protocol checking in cvsd.
 9. What should I put in the chroot directory?
    cvsd-buildroot can be used to create a chroot environment on most
    systems. There are however a few things that might also be needed.
    cvsd-buildroot uses ldd to find the libraries that are required
    but it doesn't always find all the needed libraries (for example
    libnsl.so and libnss_compat.so for most Linux systems, ld-elf.so
    for FreeBSD). If your system requires more libraries you can
    probably find out with strace (see usage of strace below).
    You can also put things in the /var/lib/cvsd/bin directory and
    rerun cvsd-buildroot to fetch the appropriate libraries. Note that
    if you want shell scripts there you should also copy /bin/sh to
    /var/lib/cvsd/bin.
10. How can I run commands from CVSROOT/{loginfo,commitinfo,...}?
    If you want to run commands from files in your CVSROOT directory
    (e.g. mail a notice on commit) you need to have a shell inside the
    chroot jail. You can just do:
    # cp -p /bin/sh /var/lib/cvsd/bin/sh
    # cvsd-buildroot /var/lib/cvsd
    and you should be good to go. Instead of /bin/sh you could
    alternatively copy some other bourne shell to /var/lib/cvsd/bin/sh
    (e.g. ash).
    Note that this may be a security problem since an attacker that
    exploits your cvs pserver now may have access to a shell on your
    system (inside a chroot jail and not as root, but a shell none the
    less).
11. Something is not working, how do I add extra debugging?
    You can start cvsd with the -d option to print extra debugging
    information to stderr. See the manual page for details.
    Some more information can be produced by using the -t option to
    cvs on the client side, e.g.:
    % cvs -d cvs -t -d :pserver:anonymous@localhost:/myrepos login
    To check if the network connection can be made you could use
    telnet to connect to the pserver, e.g.:
    % telnet localhost 2401
    If this produces "Connection refused" or something similar cvsd is
    not listening on the specified port. Check the logfiles for the
    reason.
    Rerunning cvsd-buildroot may also fix or bring to light some
    configuration problems.
    A "last resort tool" is strace (or truss or ptrace depending on
    your os). strace logs all system calls (opening files, changing
    uid, etc) and can provide useful information. Especially if you
    suspect that some files are missing from the chroot environment.
    Usage:
    % strace -f -o /tmp/logfile cvsd -d
    Then try to use cvs and see what errors are reported. On some
    occasions you may need to add -F to strace since cvs may use
    vfork()s.
    You can also build a debug-enabled cvsd binary by specifying
    '--enable-debug' with ./configure. This currently adds some
    debugging information to the pserver session.
12. What about running cvs pserver as root?
    You may need to run cvs pserver as root when you need user
    mappings to other users than cvsd (for example if you need to have
    access to the repository under different system users). You can
    instruct cvsd to run as root by setting 'Uid root' and 'Gid root'
    to cvsd.conf.
    You should set up your CVSROOT/passwd files in your repositories
    to map to the needed system users. cvsd-buildroot can be used to
    check if all the required system users are known in the chroot
    jail.
13. How do I file a bug report?
    If you find any bugs or missing features please send email to
    arthur@ch.tudelft.nl. If you are using the debian package from the
    debian servers (not the one on my personal page) you can use the
    Debian bug tracking system.
    Please include as much information as possible (platform, output
    of configure if compilation fails, output of the failure, syslog
    messages, etc). You can use the cvsd-buginfo script to provide
    your configuation information. Please provide this information
    with your bug report.
    For providing more useful information also see the question on
    debugging above.
14. Should I start the cvsd program as the cvsd user?
    No. If the pserver is set up to be run in a chroot jail the cvsd
    program needs to be started as root. After the chroot() call cvsd
    changes uid to the one specified in the configuration file
    (probably cvsd).
15. How about logging?
    Logging is configurable from the cvsd.conf configfile. See the
    cvsd.conf manual page for details.
    Logging can be done to syslog through the daemon facility or to a
    specified file. The loglevels used are debug (debugging
    information), info (starting, stopping, connections, etc), error
    (wrong configfile, execute failures, socket failures, etc) and
    critical (malloc() failures).
    If you can't find the log messages you may need to add
    daemon.*<tab>-/var/log/daemon.log
    to your /etc/syslog.conf file and/or specify a different loglevel
    in cvsd.conf.
    Also cvsd can be started with the -d option to print debugging
    information to stderr.
16. Why are tcp wrappers not working?
    You currently have to enable tcp wrappers during configure time
    using the --with-libwrap option during configure. You can
    optionally specify the prefix for where the tcp wrapper libraries
    are located.
    Some versions of tcp wrappers have problems with hosts that
    support IPv6 connections. Try to get a patched version of tcp
    wrappers or replace the 'Listen * 2401' statement in cvsd.conf
    with 'Listen 0.0.0.0 2401'.
    Don't forget that the hosts.allow and hosts.deny need to be
    located inside the chroot jail to be effective.
17. Why can't I combine some Listen options?
    Some operating systems do not fully support listening for
    connections on the same port with different protocols. E.g.
    specifying 'Listen 127.0.0.1 2401' together with 'Listen :: 2401'
    does not work on Linux (at least 2.4.20).
    You have to play around a bit to get the right combination of
    listen options to get a working solution.
18. How do I enable syslog inside the chroot jail?
    If you want to have logging in programs from within your chroot
    jail you have to tell syslogd to listen in the chroot jail also.
    With most versions of syslogd you can add '-a
    /var/lib/cvsd/dev/log' to your syslogd invocation (of cource
    replace /var/lib/cvsd with the location of your chroot jail).
    On debian systems you should edit /etc/init.d/sysklogd and modify
    the 'SYSLOGD=""' line to read:
    SYSLOGD="-a /var/lib/cvsd/dev/log"
    You may have to check the manual page fof syslogd on your system
    though.
19. When I run cvsd with debugging enabled I get "select() failed
    (ignored): Interrupted system call"
    This is a normal logging event that is common during the execution
    of cvsd. This does not indicate an error. This means that a signal
    is caught (usually the termination of one of the cvs commands)
    when listening for new connections.
20. When I try cvs update I get: "cannot create_adm_p
    /tmp/cvs-serv5153/... Permission denied
    This has to do with some changes that were made in cvs. You have
    to create an Emptydir directory in every CVSROOT directory. The
    cvsd user does not need to have write access to this directory.
21. Will you implement a reload in the init script?
    In short, no (unless you can come up with a very good reason and
    matching implementation).
    Since cvsd chroots to its jail and drops root privileges it cannot
    easily reread its configfile without keeping some privileges in
    some way. The added advantage of reloading a configfile does not
    way up (in my opinion) to the added complexity in cvsd.
    Also, current Debian policy and the LSB do not seem to allow
    reload to be an alias for restart.
    For more information see http://bugs.debian.org/286300.
22. Will you pass -R (readonly) to cvs?
    If you pass cvs the -R option it operates in read-only mode with
    the added effect of not making any lock files. This speeds up
    repository checkouts, especially simultanious checkouts, and will
    disallow any modifications. This would be a very useful option for
    a read-only pserver. The downside is that cvs no longer ensures
    correct checkouts if another cvs process is modifying the
    repository. If you have very infrequent commits or your repository
    is synchronized from a remote working repository this would not be
    a problem though.
    Some releases of cvs issue a warning when the -R option is passed,
    breaking the pserver protocol stream. A fix for this has been
    prepared but was rejected:
    http://lists.gnu.org/archive/html/bug-cvs/2004-08/msg00108.html
    The patch to cvs is here:
    http://ch.tudelft.nl/~arthur/cvsd/cvs-1.12.9-no_readonly_warning_f
    or_pserver.patch.gz. The current status is unclear.
    If you want to and are aware of the described consequences you can
    try adding -R to the CvsArgs option in cvsd.conf.

If you have any questions or remarks about cvsd please mail me at
arthur@ch.tudelft.nl.