1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44 45 46 47 48 49 50 51 52 53 54 55 56 57 58 59 60 61 62 63 64 65 66 67 68 69 70 71 72 73 74 75 76 77 78 79 80 81 82 83 84 85 86 87 88 89 90 91 92 93 94 95 96 97 98 99 100 101 102 103 104 105 106 107 108 109 110 111 112 113 114 115 116 117 118 119 120 121 122 123 124 125 126 127 128 129 130 131 132 133 134 135 136 137 138 139 140 141 142 143 144 145 146 147 148 149 150 151 152 153 154 155 156 157 158 159 160 161 162 163 164 165 166 167 168 169 170 171 172 173 174 175 176 177 178 179 180 181 182 183 184 185 186 187 188 189 190 191 192 193 194 195 196 197 198 199 200 201 202 203 204 205 206 207 208 209 210 211 212 213 214 215 216 217 218 219 220 221 222 223 224 225 226 227 228 229 230 231 232 233 234 235 236 237 238 239 240 241 242 243 244 245 246 247 248 249 250 251 252 253 254 255 256 257 258 259 260 261 262 263 264 265 266 267 268 269 270 271 272 273 274 275 276 277 278 279 280 281 282 283 284 285 286 287 288 289 290 291 292 293 294 295 296 297 298 299 300 301 302 303 304 305 306 307 308 309 310 311 312 313 314 315 316 317 318 319 320 321 322 323
|
Frequently Asked Questions for cvsd
===================================
the latest version of this FAQ can be found at
http://arthurdejong.org/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. open /dev/null failed
9. Is cvs required for running cvsd?
10. What should I put in the chroot directory?
11. How can I run commands from loginfo/commitinfo/...?
12. How do I add extra debugging?
13. What about running cvs pserver as root?
14. How do I file a bug report?
15. Should I start the cvsd program as the cvsd user?
16. How about logging?
17. Why are tcp wrappers not working?
18. Why can't I combine some Listen options?
19. How do I enable syslog inside the chroot jail?
20. Interrupted system call
21. cannot create_adm_p /tmp/cvs-serv5153/... Permission denied
22. Will you implement a reload in the init script?
23. Will you pass -R (readonly) to cvs?
24. How can I deploy cvsd using the Solaris service management facility
(smf)?
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 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.
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. cvs commands fail with "open /dev/null failed Permission denied" and
cvsd-buildroot reports "creating /var/lib/cvsd/dev devices... FAILED
(unable to use devices)"
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.
9. 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.
10. 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.
11. 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).
12. 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. 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 -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.
13. 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.
14. How do I file a bug report?
If you find any bugs or missing features please send email to
cvsd-users@lists.arthurdejong.org. 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.
15. 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).
16. Does cvsd do 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.
17. 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.
18. 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 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.
19. 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.
20. 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.
21. 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.
22. 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.
23. 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://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.
24. How can I deploy cvsd as a non-root service as part of the Solaris service
management facility (smf)?
Add the following lines to the following files (fine-tune the paths
depending on your installation):
/etc/security/auth_attr:
solaris.smf.manage.cvsd:::Manage cvsd service states::
solaris.smf.value.cvsd:::Change cvsd value properties:::
/etc/security/exec_attr:
Cvsd Administration:solaris:cmd:::/etc/init.d/cvsd':uid=cvsd
/etc/security/prof_attr:
Cvsd Administration::::auths=solaris.smf.manage.cvsd,solaris.smf.value.cvsd
Download the cvsd.xml (http://arthurdejong.org/cvsd/smf/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.
|