Open Source / Free Software developer
In no particular order:
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.
Not really anything to do with cvsd but here goes:
% export CVS_RSH=ssh
% cvs -d remotehost:repositorypath <whatever cvscommand>You need an 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.
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.
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.
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.
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.
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=noIf you really want to use PAM to do the authentication you should copy all needed PAM modules and configuration files into the chroot directory.
The cvs pservers needs to open several devices (most notably /dev/null) for handling requests. The file system on which the chroot jail was created needs to suppoed these device entries. This means that the file system should not be mounted with the "nodev" option. The "noexec" mount option will also cause problems.
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.
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.
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/cvsdand 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).
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 -t -d :pserver:anonymous@localhost:/myrepos loginTo check if the network connection can be made you could use telnet to connect to the pserver, e.g.:
% telnet localhost 2401If 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. Also a script to check for the most common configuration problems (cvsd-buginfo) is included in the distribution.
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 -dThen 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.
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.
If you find any bugs or missing features please send email to cvsd-users@lists.arthurdejong.org. If you are using the package from the Debian servers 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.
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).
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.logto 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.
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.
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 on 2.4.20).
You may have to play around a bit to get the right combination of listen options to get a working solution.
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.
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.
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.
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 https://bugs.debian.org/286300.
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: https://lists.gnu.org/archive/html/bug-cvs/2004-08/msg00108.html The patch to cvs is here: https://arthurdejong.org/cvsd/cvs-1.12.9-no_readonly_warning_for_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.
Add the following lines to the following files (fine-tune the paths depending on your installation):
solaris.smf.manage.cvsd:::Manage cvsd service states::
solaris.smf.value.cvsd:::Change cvsd value properties:::Cvsd Administration:solaris:cmd:::/etc/init.d/cvsd':uid=cvsdCvsd Administration::::auths=solaris.smf.manage.cvsd,solaris.smf.value.cvsdDownload the cvsd.xml file (you may also need to fine-tune paths here) and use svccfg validate cvsd.xml;svccfg import cvsd.xml to import the file.
Finally, add the "Cvsd Administration" profile to a user in /etc/user_attr. This user should should now be able to use svcadm to enable and disable cvsd.
If you have any questions or remarks about cvsd please send an email to cvsd-users@lists.arthurdejong.org.