~ubuntu-branches/ubuntu/hardy/cvsd/hardy : revision 4

30

22. Will you pass -R (readonly) to cvs?

31

32

1. How secure is cvsd?

33

The only security cvsd adds to a cvs pserver is in the fact that

34

possible exploits and misconfigurations in the server will most

35

likely not result in the compromise of the machine (don't forget

36

the disclaimer though). cvsd does not improve the inherent

37

weaknesses of the pserver protocol such as cleartext passwords,

38

use cvs over ssh for that.

33

34

The only security cvsd adds to a cvs pserver is in the fact that possible

35

exploits and misconfigurations in the server will most likely not result

36

in the compromise of the machine (don't forget the disclaimer though).

37

cvsd does not improve the inherent weaknesses of the pserver protocol such

38

as cleartext passwords, use cvs over ssh for that.

39

40

2. How does one use cvs over ssh?

41

40

42

Not really anything to do with cvsd but here goes:

41

43

% export CVS_RSH=ssh

42

44

% cvs -d remotehost:repositorypath <whatever cvscommand>

43

You need a ssh account on the remotehost and access to the

44

repositorypath. This setup is particularly useful for secure

45

authenticated development access, while cvsd is more useful for

46

public read-only access.

45

You need an ssh account on the remotehost and access to the

46

repositorypath. This setup is particularly useful for secure authenticated

47

development access, while cvsd is more useful for public read-only access.

48

47

49

3. 'cvs -d ... checkout .' fails with something like "Assertion

48

`*short_repos++ == '/'' failed." but other checkouts work fine,

49

what's wrong?

50

Older versions of cvs (at least 1.10.7 but 1.11.1p1 is fixed) have

51

a bug where the repository is a direct descendant of the root

52

directory. You should probably upgrade cvs on the server side.

53

4. cvs login works but cvs checkout or other commands fail with

54

"setgid failed: Operation not permitted"

55

This can happen when you run cvsd as non-root (which is

56

recommended) and didn't set up your repository passwd file

57

(CVSROOT/passwd) correctly. The repository passwd files should

58

contain mappings of cvs users to the user you specified in

59

cvsd.conf. If no mapping is present cvs tries to become the

60

"original" user and fail because it's not running as root. Your

50

`*short_repos++ == '/'' failed." but other checkouts work fine, what's

51

wrong?

52

53

Older versions of cvs (at least 1.10.7 but 1.11.1p1 is fixed) have a bug

54

where the repository is a direct descendant of the root directory. You

55

should probably upgrade cvs on the server side.

56

57

4. cvs login works but cvs checkout or other commands fail with "setgid

58

failed: Operation not permitted"

59

60

This can happen when you run cvsd as non-root (which is recommended) and

61

didn't set up your repository passwd file (CVSROOT/passwd) correctly. The

62

repository passwd files should contain mappings of cvs users to the user

63

you specified in cvsd.conf. If no mapping is present cvs tries to become

64

the "original" user and fail because it's not running as root. Your

61

65

repository passwd files should look like:

62

66

anonymous:XGPg1ub8xh70U:cvsd

63

Another possibility is that your system uses something different

64

for providing user information (nis/ldap/etc) and that your chroot

65

passwd file (e.g. /var/lib/cvsd/etc/passwd) does not match the

66

system passwd database (any more). This is especially important if

67

your chroot jail is on an nfs filesystem.

68

In this case it may be needed to rerun cvsd-buildroot and check

69

it's output (and possibly the output of cvsd-buginfo) to see which

70

users are missing.

71

5. cvs login works but cvs checkout or other commands fail with

72

"setgroups: Operation not permitted"

67

Another possibility is that your system uses something different for

68

providing user information (nis/ldap/etc) and that your chroot passwd file

69

(e.g. /var/lib/cvsd/etc/passwd) does not match the system passwd database

70

(any more). This is especially important if your chroot jail is on an nfs

71

filesystem.

72

In this case it may be needed to rerun cvsd-buildroot and check it's

73

output (and possibly the output of cvsd-buginfo) to see which users are

74

missing.

75

76

5. cvs login works but cvs checkout or other commands fail with "setgroups:

77

Operation not permitted"

78

73

79

Also see the previous question.

74

Setgroups is called to change the supplemental groups the user is

75

in. This can happen when /etc/groups exists inside the chroot jail

76

and the cvsd user is member of some groups.

77

6. cvs login works but cvs checkout or other commands fail with

78

"cvsd: no such user" or "cvsd: no such system user"

80

Setgroups is called to change the supplemental groups the user is in. This

81

can happen when /etc/groups exists inside the chroot jail and the cvsd

82

user is member of some groups.

83

84

6. cvs login works but cvs checkout or other commands fail with "cvsd: no

85

such user" or "cvsd: no such system user"

86

79

87

The cvs pserver maps users found in the repository passwd file

80

(CVSROOT/passwd) to users in the system passwd file. Since cvs is

81

running in a chroot environment the system passwd file is located

82

in /var/lib/cvsd/etc/passwd (depending on what you set your

83

RootJail to). If you set up user mappings correctly there should

84

be a cvsd user in the passwd file.

85

cvsd-buildroot checks the chroot jail's /etc/passwd file and adds

86

users from the system /etc/passwd if needed (and generates

87

warnings for missing users).

88

If you need ldap or similar methods to provide user id information

89

you need to set up the proper configuration inside the chroot

90

jail.

91

7. cvs commands fail with "unrecognized auth response from server:

92

pam failed to release authenticator."

93

Your repository is probably configured to use pam as an

94

authentication mechanism. Edit your repository configuration file

95

(CVSROOT/config) and set the following options:

88

(CVSROOT/passwd) to users in the system passwd file. Since cvs is running

89

in a chroot environment the system passwd file is located in

90

/var/lib/cvsd/etc/passwd (depending on what you set your RootJail to). If

91

you set up user mappings correctly there should be a cvsd user in the

92

passwd file.

93

cvsd-buildroot checks the chroot jail's /etc/passwd file and adds users

94

from the system /etc/passwd if needed (and generates warnings for missing

95

users).

96

If you need ldap or similar methods to provide user id information you

97

need to set up the proper configuration inside the chroot jail.

98

99

7. cvs commands fail with "unrecognized auth response from server: pam failed

100

to release authenticator."

101

102

Your repository is probably configured to use pam as an authentication

103

mechanism. Edit your repository configuration file (CVSROOT/config) and

104

set the following options:

96

105

SystemAuth=no PamAuth=no

97

If you really want to use PAM to do the authentication you should

98

copy all needed PAM modules and configuration files into the

99

chroot directory.

106

If you really want to use PAM to do the authentication you should copy all

107

needed PAM modules and configuration files into the chroot directory.

108

100

109

8. Is cvs required for running cvsd?

101

Yes. cvsd is just a wrapper for running cvs in pserver mode. It

102

runs cvs in a chroot jail and possibly sets resource limitations.

103

The complete protocol handling is done by cvs although there are

104

some plans to do some protocol checking in cvsd.

110

111

Yes. cvsd is just a wrapper for running cvs in pserver mode. It runs cvs

112

in a chroot jail and possibly sets resource limitations. The complete

113

protocol handling is done by cvs although there are some plans to do some

114

protocol checking in cvsd.

115

105

116

9. What should I put in the chroot directory?

106

cvsd-buildroot can be used to create a chroot environment on most

107

systems. There are however a few things that might also be needed.

108

cvsd-buildroot uses ldd to find the libraries that are required

109

but it doesn't always find all the needed libraries (for example

110

libnsl.so and libnss_compat.so for most Linux systems, ld-elf.so

111

for FreeBSD). If your system requires more libraries you can

112

probably find out with strace (see usage of strace below).

113

You can also put things in the /var/lib/cvsd/bin directory and

114

rerun cvsd-buildroot to fetch the appropriate libraries. Note that

115

if you want shell scripts there you should also copy /bin/sh to

116

/var/lib/cvsd/bin.

117

118

cvsd-buildroot can be used to create a chroot environment on most systems.

119

There are however a few things that might also be needed. cvsd-buildroot

120

uses ldd to find the libraries that are required but it doesn't always

121

find all the needed libraries (for example libnsl.so and libnss_compat.so

122

for most Linux systems, ld-elf.so for FreeBSD). If your system requires

123

more libraries you can probably find out with strace (see usage of strace

124

below).

125

You can also put things in the /var/lib/cvsd/bin directory and rerun

126

cvsd-buildroot to fetch the appropriate libraries. Note that if you want

127

shell scripts there you should also copy /bin/sh to /var/lib/cvsd/bin.

128

117

129

10. How can I run commands from CVSROOT/{loginfo,commitinfo,...}?

118

If you want to run commands from files in your CVSROOT directory

119

(e.g. mail a notice on commit) you need to have a shell inside the

120

chroot jail. You can just do:

130

131

If you want to run commands from files in your CVSROOT directory (e.g.

132

mail a notice on commit) you need to have a shell inside the chroot jail.

133

You can just do:

121

134

# cp -p /bin/sh /var/lib/cvsd/bin/sh

122

135

# cvsd-buildroot /var/lib/cvsd

123

and you should be good to go. Instead of /bin/sh you could

124

alternatively copy some other bourne shell to /var/lib/cvsd/bin/sh

125

(e.g. ash).

126

Note that this may be a security problem since an attacker that

127

exploits your cvs pserver now may have access to a shell on your

128

system (inside a chroot jail and not as root, but a shell none the

129

less).

136

and you should be good to go. Instead of /bin/sh you could alternatively

137

copy some other bourne shell to /var/lib/cvsd/bin/sh (e.g. ash).

138

Note that this may be a security problem since an attacker that exploits

139

your cvs pserver now may have access to a shell on your system (inside a

140

chroot jail and not as root, but a shell none the less).

141

130

142

11. Something is not working, how do I add extra debugging?

131

You can start cvsd with the -d option to print extra debugging

132

information to stderr. See the manual page for details.

133

Some more information can be produced by using the -t option to

134

cvs on the client side, e.g.:

143

144

You can start cvsd with the -d option to print extra debugging information

145

to stderr. See the manual page for details. Some more information can be

146

produced by using the -t option to cvs on the client side, e.g.:

135

147

% cvs -d cvs -t -d :pserver:anonymous@localhost:/myrepos login

136

To check if the network connection can be made you could use

137

telnet to connect to the pserver, e.g.:

148

To check if the network connection can be made you could use telnet to

149

connect to the pserver, e.g.:

138

150

% telnet localhost 2401

139

If this produces "Connection refused" or something similar cvsd is

140

not listening on the specified port. Check the logfiles for the

141

reason.

142

Rerunning cvsd-buildroot may also fix or bring to light some

143

configuration problems.

144

A "last resort tool" is strace (or truss or ptrace depending on

145

your os). strace logs all system calls (opening files, changing

146

uid, etc) and can provide useful information. Especially if you

147

suspect that some files are missing from the chroot environment.

148

Usage:

151

If this produces "Connection refused" or something similar cvsd is not

152

listening on the specified port. Check the logfiles for the reason.

153

Rerunning cvsd-buildroot may also fix or bring to light some configuration

154

problems.

155

A "last resort tool" is strace (or truss or ptrace depending on your os).

156

strace logs all system calls (opening files, changing uid, etc) and can

157

provide useful information. Especially if you suspect that some files are

158

missing from the chroot environment. Usage:

149

159

% strace -f -o /tmp/logfile cvsd -d

150

Then try to use cvs and see what errors are reported. On some

151

occasions you may need to add -F to strace since cvs may use

152

vfork()s.

160

Then try to use cvs and see what errors are reported. On some occasions

161

you may need to add -F to strace since cvs may use vfork()s.

153

162

You can also build a debug-enabled cvsd binary by specifying

154

'--enable-debug' with ./configure. This currently adds some

155

debugging information to the pserver session.

163

'--enable-debug' with ./configure. This currently adds some debugging

164

information to the pserver session.

165

156

166

12. What about running cvs pserver as root?

157

You may need to run cvs pserver as root when you need user

158

mappings to other users than cvsd (for example if you need to have

159

access to the repository under different system users). You can

160

instruct cvsd to run as root by setting 'Uid root' and 'Gid root'

161

to cvsd.conf.

162

You should set up your CVSROOT/passwd files in your repositories

163

to map to the needed system users. cvsd-buildroot can be used to

164

check if all the required system users are known in the chroot

165

jail.

167

168

You may need to run cvs pserver as root when you need user mappings to

169

other users than cvsd (for example if you need to have access to the

170

repository under different system users). You can instruct cvsd to run as

171

root by setting 'Uid root' and 'Gid root' to cvsd.conf. You should set up

172

your CVSROOT/passwd files in your repositories to map to the needed system

173

users. cvsd-buildroot can be used to check if all the required system

174

users are known in the chroot jail.

175

166

176

13. How do I file a bug report?

177

167

178

If you find any bugs or missing features please send email to

168

arthur@ch.tudelft.nl. If you are using the debian package from the

169

debian servers (not the one on my personal page) you can use the

170

Debian bug tracking system.

171

Please include as much information as possible (platform, output

172

of configure if compilation fails, output of the failure, syslog

173

messages, etc). You can use the cvsd-buginfo script to provide

174

your configuation information. Please provide this information

175

with your bug report.

176

For providing more useful information also see the question on

177

debugging above.

179

arthur@ch.tudelft.nl. If you are using the debian package from the debian

180

servers (not the one on my personal page) you can use the Debian bug

181

tracking system.

182

Please include as much information as possible (platform, output of

183

configure if compilation fails, output of the failure, syslog messages,

184

etc). You can use the cvsd-buginfo script to provide your configuation

185

information. Please provide this information with your bug report.

186

For providing more useful information also see the question on debugging

187

above.

188

178

189

14. Should I start the cvsd program as the cvsd user?

179

No. If the pserver is set up to be run in a chroot jail the cvsd

180

program needs to be started as root. After the chroot() call cvsd

181

changes uid to the one specified in the configuration file

182

(probably cvsd).

190

191

No. If the pserver is set up to be run in a chroot jail the cvsd program

192

needs to be started as root. After the chroot() call cvsd changes uid to

193

the one specified in the configuration file (probably cvsd).

194

183

195

15. How about logging?

184

Logging is configurable from the cvsd.conf configfile. See the

185

cvsd.conf manual page for details.

196

197

Logging is configurable from the cvsd.conf configfile. See the cvsd.conf

198

manual page for details.

186

199

Logging can be done to syslog through the daemon facility or to a

187

specified file. The loglevels used are debug (debugging

188

information), info (starting, stopping, connections, etc), error

189

(wrong configfile, execute failures, socket failures, etc) and

190

critical (malloc() failures).

200

specified file. The loglevels used are debug (debugging information), info

201

(starting, stopping, connections, etc), error (wrong configfile, execute

202

failures, socket failures, etc) and critical (malloc() failures).

191

203

If you can't find the log messages you may need to add

192

204

daemon.*<tab>-/var/log/daemon.log

193

to your /etc/syslog.conf file and/or specify a different loglevel

194

in cvsd.conf.

195

Also cvsd can be started with the -d option to print debugging

196

information to stderr.

205

to your /etc/syslog.conf file and/or specify a different loglevel in

206

cvsd.conf.

207

Also cvsd can be started with the -d option to print debugging information

208

to stderr.

209

197

210

16. Why are tcp wrappers not working?

198

You currently have to enable tcp wrappers during configure time

199

using the --with-libwrap option during configure. You can

200

optionally specify the prefix for where the tcp wrapper libraries

201

are located.

202

Some versions of tcp wrappers have problems with hosts that

203

support IPv6 connections. Try to get a patched version of tcp

204

wrappers or replace the 'Listen * 2401' statement in cvsd.conf

205

with 'Listen 0.0.0.0 2401'.

206

Don't forget that the hosts.allow and hosts.deny need to be

207

located inside the chroot jail to be effective.

211

212

You currently have to enable tcp wrappers during configure time using the

213

--with-libwrap option during configure. You can optionally specify the

214

prefix for where the tcp wrapper libraries are located.

215

Some versions of tcp wrappers have problems with hosts that support IPv6

216

connections. Try to get a patched version of tcp wrappers or replace the

217

'Listen * 2401' statement in cvsd.conf with 'Listen 0.0.0.0 2401'.

218

Don't forget that the hosts.allow and hosts.deny need to be located inside

219

the chroot jail to be effective.

220

208

221

17. Why can't I combine some Listen options?

209

Some operating systems do not fully support listening for

210

connections on the same port with different protocols. E.g.

211

specifying 'Listen 127.0.0.1 2401' together with 'Listen :: 2401'

212

does not work on Linux (at least 2.4.20).

213

You have to play around a bit to get the right combination of

214

listen options to get a working solution.

222

223

Some operating systems do not fully support listening for connections on

224

the same port with different protocols. E.g. specifying 'Listen 127.0.0.1

225

2401' together with 'Listen :: 2401' does not work on Linux (at least

226

2.4.20).

227

You have to play around a bit to get the right combination of listen

228

options to get a working solution.

229

215

230

18. How do I enable syslog inside the chroot jail?

216

If you want to have logging in programs from within your chroot

217

jail you have to tell syslogd to listen in the chroot jail also.

218

With most versions of syslogd you can add '-a

219

/var/lib/cvsd/dev/log' to your syslogd invocation (of cource

220

replace /var/lib/cvsd with the location of your chroot jail).

221

On debian systems you should edit /etc/init.d/sysklogd and modify

222

the 'SYSLOGD=""' line to read:

231

232

If you want to have logging in programs from within your chroot jail you

233

have to tell syslogd to listen in the chroot jail also. With most versions

234

of syslogd you can add '-a /var/lib/cvsd/dev/log' to your syslogd

235

invocation (of cource replace /var/lib/cvsd with the location of your

236

chroot jail). On debian systems you should edit /etc/init.d/sysklogd and

237

modify the 'SYSLOGD=""' line to read:

223

238

SYSLOGD="-a /var/lib/cvsd/dev/log"

224

You may have to check the manual page fof syslogd on your system

225

though.

226

19. When I run cvsd with debugging enabled I get "select() failed

227

(ignored): Interrupted system call"

228

This is a normal logging event that is common during the execution

229

of cvsd. This does not indicate an error. This means that a signal

230

is caught (usually the termination of one of the cvs commands)

231

when listening for new connections.

232

20. When I try cvs update I get: "cannot create_adm_p

233

/tmp/cvs-serv5153/... Permission denied

234

This has to do with some changes that were made in cvs. You have

235

to create an Emptydir directory in every CVSROOT directory. The

236

cvsd user does not need to have write access to this directory.

239

You may have to check the manual page fof syslogd on your system though.

240

241

19. When I run cvsd with debugging enabled I get "select() failed (ignored):

242

Interrupted system call"

243

244

This is a normal logging event that is common during the execution of

245

cvsd. This does not indicate an error. This means that a signal is caught

246

(usually the termination of one of the cvs commands) when listening for

247

new connections.

248

249

20. When I try cvs update I get: "cannot create_adm_p /tmp/cvs-serv5153/...

250

Permission denied

251

252

This has to do with some changes that were made in cvs. You have to create

253

an Emptydir directory in every CVSROOT directory. The cvsd user does not

254

need to have write access to this directory.

255

237

256

21. Will you implement a reload in the init script?

238

In short, no (unless you can come up with a very good reason and

239

matching implementation).

240

Since cvsd chroots to its jail and drops root privileges it cannot

241

easily reread its configfile without keeping some privileges in

242

some way. The added advantage of reloading a configfile does not

243

way up (in my opinion) to the added complexity in cvsd.

244

Also, current Debian policy and the LSB do not seem to allow

245

reload to be an alias for restart.

257

258

In short, no (unless you can come up with a very good reason and matching

259

implementation).

260

Since cvsd chroots to its jail and drops root privileges it cannot easily

261

reread its configfile without keeping some privileges in some way. The

262

added advantage of reloading a configfile does not way up (in my opinion)

263

to the added complexity in cvsd.

264

Also, current Debian policy and the LSB do not seem to allow reload to be

265

an alias for restart.

246

266

For more information see http://bugs.debian.org/286300.

267

247

268

22. Will you pass -R (readonly) to cvs?

248

If you pass cvs the -R option it operates in read-only mode with

249

the added effect of not making any lock files. This speeds up

250

repository checkouts, especially simultanious checkouts, and will

251

disallow any modifications. This would be a very useful option for

252

a read-only pserver. The downside is that cvs no longer ensures

253

correct checkouts if another cvs process is modifying the

254

repository. If you have very infrequent commits or your repository

255

is synchronized from a remote working repository this would not be

256

a problem though.

269

270

If you pass cvs the -R option it operates in read-only mode with the added

271

effect of not making any lock files. This speeds up repository checkouts,

272

especially simultanious checkouts, and will disallow any modifications.

273

This would be a very useful option for a read-only pserver. The downside

274

is that cvs no longer ensures correct checkouts if another cvs process is

275

modifying the repository. If you have very infrequent commits or your

276

repository is synchronized from a remote working repository this would not

277

be a problem though.

257

278

Some releases of cvs issue a warning when the -R option is passed,

258

breaking the pserver protocol stream. A fix for this has been

259

prepared but was rejected:

260

http://lists.gnu.org/archive/html/bug-cvs/2004-08/msg00108.html

261

The patch to cvs is here:

262

http://ch.tudelft.nl/~arthur/cvsd/cvs-1.12.9-no_readonly_warning_f

263

or_pserver.patch.gz. The current status is unclear.

264

If you want to and are aware of the described consequences you can

265

try adding -R to the CvsArgs option in cvsd.conf.

279

breaking the pserver protocol stream. A fix for this has been prepared but

280

was rejected:

281

http://lists.gnu.org/archive/html/bug-cvs/2004-08/msg00108.html The

282

patch to cvs is here:

283

http://ch.tudelft.nl/~arthur/cvsd/cvs-1.12.9-no_readonly_warning_for_pserver.patch.gz.

284

The current status is unclear. If you want to and are aware of the

285

described consequences you can try adding -R to the CvsArgs option in

286

cvsd.conf.

266

287

267

288

If you have any questions or remarks about cvsd please mail me at

268

arthur@ch.tudelft.nl.