~msapiro/mailman/topics : revision 1014

1

The following is the contents of the post at

2

<http://mail.python.org/pipermail/mailman-developers/2004-October/017343.html>.

3

4

The actual patch is at redhat_fhs.patch in this (contrib/) directory.

5

6

Note that this patch only patches configure.in, so if you apply this patch,

7

you need to then run GNU autoconf to build the patched ./configure.

8

9

10

[Mailman-Developers] FHS installation changes

11

John Dennis jdennis at redhat.com

12

Mon Oct 18 22:26:21 CEST 2004

13

14

Overview:

15

---------

16

17

Earlier I wrote about our (Red Hat's) desire to make mailman be FHS

18

compliant, in part to allow mailman to fall under the protection of

19

SELinux security policy which is file and directory based and as a

20

consequence much easier to author when packages install into canonical

21

locations (e.g. FHS).

22

23

Previously we had installed all of mailman under /var/mailman

24

(prefix=var_prefix=/var/mailman) and I had proposed a much simpler

25

change of just setting prefix=/usr/lib/mailman. This took care of the

26

majority of SELinux issues and limited the scope of changes. There was

27

a concern that sites and administrators who were familiar either with

28

our RPM, the upstream package, or were working with an existing

29

installation would run afoul of the location changes and keeping them

30

to absolute minimum was advantageous. However a few folks in private

31

email pointed out that if changes were going to occur its best to do

32

it all at once and not piecemeal, in other words endure the pain once.

33

34

Thus I embarked on an exercise to make everything FHS compliant. There

35

are two reasons I'm addressing the developer community here:

36

37

1) I want to apprise you of the exact changes, their rational, provide

38

a patch against 2.1.5 and solicit review.

39

40

2) Test the results.

41

42

Description:

43

------------

44

45

Currently the configuration allows for partitioning the mailman

46

installation between two installation roots, prefix for non-modifiable

47

files and var_prefix for variable data. This is a great start and

48

covers 90% of the installation, but there remains a small set of items

49

which even in this scheme are not FHS compliant, in summary:

50

51

1) config files located under /etc

52

53

2) pid file located under /var/run

54

55

3) queue files located under /var/spool

56

57

4) lock files located /var/lock

58

59

5) log files located under /var/log

60

61

I think one could characterize the competing installation philosophies

62

as follows:

63

64

Mailman not knowing what type of system its going to be installed on

65

elects to group all of its files together (makes perfect sense). FHS

66

on the other hand says most packages share common traits and we group

67

by functional component thus spreading out package installations

68

across a diverse set of directories.

69

70

Implementation:

71

---------------

72

73

I discovered I had to add some new directories to configure and alter

74

some of the *_DIR variables in Defaults.py.in so they pick up their

75

values from configure. My strategy was to allow configure when run

76

without providing any other parameters to produce the exact same set

77

of installation defaults as previously existed so unless you specify a

78

different installation mapping a user won't see any change.

79

80

Configure added:

81

82

--with_lock_dir

83

--with_log_dir

84

--with_config_dir

85

--with_data_dir

86

--with_pid_dir

87

--with_queue_dir

88

89

I also modified bin/check_perms so it was aware of the new directory

90

specifications. The patch also made a few non FHS fixes to the install

91

target of the Makefiles, some generic issues were discovered when

92

testing check_perms. Those changes included: setting SETGID on the root

93

prefix and var_prefix directories, check_perms demands all

94

directories, including the roots are SETGID. The messages Makefile was

95

creating a two level directory hierarchy but only setting SETGID on

96

the child. Some of the "make install" logic seemed to depend on the

97

property that new child directories created under a parent that was

98

SETGID inherits the SETGID property. To the best of my understanding

99

this is true only on Linux and Solaris and not generally portable. I

100

replaced the use of the local mkinstalldirs (and subsequent chmod g+s)

101

with what I believe is much more standard "install -d" and with the

102

SETGID as part of the mode. All directories are created this way,

103

nothing depends on inheritance. I also removed some ancient Makefile

104

cruft that is no longer in use, variables no longer initialized by

105

configure, etc. (just confusing, accidents waiting to happen if

106

someone thought it was valid).

107

108

Issues:

109

-------

110

111

Most of the changes were isolated to whole directories and were well

112

defined. Only the contents of DATA_DIR required splitting its contents

113

across more than one directory. DATA_DIR contained both pickle files

114

created during processing and what would be characterized as

115

configuration files (e.g. password files, MTA alias

116

files. sitelist.cfg). A new directory CONFIG_DIR was created (in FHS

117

its /etc/mailman) to hold what has traditionally been in /etc

118

(e.g. configuration, passwords, aliases, etc). The other things that

119

were in DATA_DIR was left there.

120

121

The mailman configuration file presented the biggest challenge and the

122

one exception to FHS. The culprit is mm_cfg.py. This is really

123

mailman's configuration file and it should be located in CONFIG_DIR

124

(/etc/mailman). But there were several major problems with moving that

125

file there.

126

127

1) It's executable python code, not a text file containing

128

configuration parameters. Executable code should be in a "lib" or

129

"bin" location. Why is this an issue? Because SELinux pays very

130

close attention to who can execute and with precise control over a

131

host of run time operations, its often based on directory

132

location. But most importantly config files have to be editable,

133

security properties transit when modified and new files pick up

134

security properties of the directory that contains the file. We do

135

not want any file created (or modified) in a configuration

136

directory to pick up security permissions granting execution

137

rights or for that matter any other run time security permissions.

138

139

2) The import of mm_cfg and its directory (Mailman) is all through the

140

code, it would be very invasive to change. If mm_cfg continues to be

141

executable python code as opposed to a text file then paths.py

142

would have to be altered to prepend /etc/mailman to the import

143

path, another significant security violation.

144

145

3) Any experienced mailman admin will know that mm_cfg.py is located

146

with the rest of the mailman executable code under $prefix/Mailman

147

and will expect to find this critical file there.

148

149

I concluded for the above reasons that mm_cfg.py in the 2.1.x

150

time frame was best handled as an FHS exception. Our rpm does however

151

create a symbolic link from /etc/mailman/mm_cfg.py to

152

$prefix/Mailman/mm_cfg.py so that it "appears" in configuration

153

directory. This will prepare admins to start looking for mm_cfg along

154

with the other configuration files. Note that security policies do not

155

transit across links therefore there are no security policy issues

156

with the sym link in /etc/mailman. Hopefully in MM 3.0 the

157

configuration file will be textural which will eliminate the security

158

policy issue. Also note that sitelist.cfg was completely moved to

159

/etc/mailman as that is not executed, but rather "evaluated" (I think

160

evaluation in /etc is fine, but I'm not 100% positive :-).

161

162

Request for testing:

163

--------------------

164

165

I have created RPM's with the changes outlined above and documented

166

below, you may obtain them here:

167

168

ftp://people.redhat.com/jdennis/mailman-2.1.5-26.i386.rpm

169

ftp://people.redhat.com/jdennis/mailman-2.1.5-26.src.rpm

170

171

I have tested the new rpm and have not found any problems. The

172

modified check_perms does not report any problems. But I'm well aware

173

my testing is limited and my comprehension of mailman is limited, it

174

is inevitable something has been missed that only wider testing will

175

reveal and I would appreciate that testing by experts. These changes

176

are slated to appear in our Fedora Core 3 release which is closing in

177

a couple of days in preparation for release. Testing prior to that

178

close would be appreciated. Note that with Fedora Core 3 SELinux will

179

be enabled by default in "targeted mode". This means that SELinux

180

policy will be applied to key system services only, mail and hence

181

mailman is one of those key system services. Ideally any testing

182

should be done from "rawhide" with the 2.1.5-26 version of mailman and

183

the new matching SELinux security policy, but I would be perfectly

184

happy for any testing of the basic rpm even if its not running under

185

targeted security policy.

186

187

Patch File:

188

-----------

189

190

Attached is the patch made against a virgin 2.1.5 tarball with the

191

changes outlined above.

192

193

194

User / Admin Documentation:

195

---------------------------

196

197

The following is what I prepared for our installation documentation

198

which can be found in /usr/share/doc/mailman-*

199

200

201

202

IMPORTANT NOTE FOR USERS UPGRADING FROM A PREVIOUS RED HAT MAILMAN

203

INSTALLATION OR THOSE FAMILIAR WITH "STANDARD MAILMAN INSTALLATIONS"

204

205

Earlier Red Hat mailman rpms installed all of the mailman files under

206

/var/mailman. This did not conform to the Filesystem Hierarchy

207

Standard (FHS) and created security violations when SELinux is

208

enabled. As of mailman-2.1.5-21 the following directory and file

209

changes occurred:

210

211

variable data (e.g. lists) is in /var/lib/mailman, library code,

212

executables, and scripts are located in /usr/lib/mailman, lock files are in

213

/var/lock/mailman, the pid file is in /var/run/mailman, qfiles are in /var/spool/mailman,

214

and configuration files have been moved to the new /etc/mailman

215

216

If you previously had mailman installed and have edited files in

217

/var/mailman (e.g. configuration) you will need to move those changes

218

to their new locations.

219

220

The mapping of old locations to new locations is as follows:

221

222

Directory Mapping:

223

/var/mailman --> /var/lib/mailman

224

/var/mailman/Mailman --> /usr/lib/mailman/Mailman

225

/var/mailman/archives --> /var/lib/mailman/archives

226

/var/mailman/bin --> /usr/lib/mailman/bin

227

/var/mailman/cgi-bin --> /usr/lib/mailman/cgi-bin

228

/var/mailman/cron --> /usr/lib/mailman/cron

229

/var/mailman/data --> /var/lib/mailman/data

230

/var/mailman/lists --> /var/lib/mailman/lists

231

/var/mailman/locks --> /var/lock/mailman

232

/var/mailman/logs --> /var/log/mailman

233

/var/mailman/mail --> /usr/lib/mailman/mail

234

/var/mailman/messages --> /usr/lib/mailman/messages

235

/var/mailman/pythonlib --> /usr/lib/mailman/pythonlib

236

/var/mailman/qfiles --> /var/spool/mailman

237

/var/spool/mailman/qfiles --> /var/spool/mailman

238

/var/mailman/scripts --> /usr/lib/mailman/scripts

239

/var/mailman/spam --> /var/lib/mailman/spam

240

/var/mailman/templates --> /usr/lib/mailman/templates

241

/var/mailman/tests --> /usr/lib/mailman/tests

242

243

File Mapping:

244

/var/mailman/data/adm.pw --> /etc/mailman/adm.pw

245

/var/mailman/data/creator.pw --> /etc/mailman/creator.pw

246

/var/mailman/data/aliases --> /etc/mailman/aliases

247

/var/mailman/data/virtual-mailman --> /etc/mailman/virtual-mailman

248

/var/mailman/data/sitelist.cfg --> /etc/mailman/sitelist.cfg

249

/var/mailman/data/master-qrunner.pid --> /var/run/mailman/master-qrunner.pid

250

251

Discussion of directory and file relocation:

252

253

Two new directories were created and three existing directories which

254

were hardcoded are now configurable.

255

256

PID_DIR is used to hold the process id and is new because FHS wants

257

pid files to be located in /var/run. The FHS says when there is only a

258

single pid file it should be located in /var/run/<name>.pid, and when

259

there are multiple pid's files they should be located together in a

260

subdirectory, /var/run/<name>/. Currently mailman only has a single

261

pid file, but it does have multiple processes (qrunners). Also SELinux

262

security policy is easier to write if processes are segregated into

263

individual subdirectories. Therefore we elected to place the mailman

264

pid file in its own subdirectory, there is some debate if this is 100%

265

FHS compliant because there is only currently a single pid file, but

266

this gives us greater future flexibility and is in the spirit of FHS.

267

268

CONFIG_DIR is used to hold the site configuration files. FHS wants

269

configuration files stored in /etc/mailman. Previously configuration

270

files were mixed in with data files in DATA_DIR and with the run-time

271

code (e.g. Mailman/mm_cfg.py). CONFIG_DIR continues to exist but is

272

now restricted to data files (e.g. python pickle files). The password

273

files, alias files, and .cfg (e.g. sitelist.cfg) files have been moved

274

to CONFIG_DIR. mm_cfg.py which is the primary mailman configuration

275

file was presented a bit of a dilemma. In theory it should be located

276

in /etc/mailman, however it is executable code which argues it should

277

be located with the other executable files, it has traditionally lived

278

in $PREFIX/Mailman and experienced mailman admins will expect to find

279

it there. Modifying all the mm_cfg import statements and paths.py was

280

believed to be too invasive a change, and technically its part of the

281

"Mailman" package and moving it would take it out of the package

282

(although currently I don't think that presents any known

283

issues). Instead a compromise approach was adopted, mm_cfg.py is

284

symbolically linked into the /etc/mailman directory pointing to

285

$PREFIX/Mailman/mm_cfg.py. Thus mm_cfg.py "appears" in the

286

configuration directory but retains its traditional location, this was

287

deemed a reasonable compromise for the mailman 2.1.x timeframe.

288

289

sitelist.cfg has a symbolic link in its old location in the DATA_DIR

290

pointing to its new location in the CONFIG_DIR.

291

292

New Directories (can be specified as parameter to configure):

293

294

CONFIG_DIR: default=$VAR_PREFIX/data FHS=/etc/mailman

295

PID_DIR default=$VAR_PREFIX/data FHS=/var/run/mailman

296

297

Existing directories that can now be specified as parameter to configure:

298

299

LOCK_DIR: default=$VAR_PREFIX/locks FHS=/var/lock/mailman

300

LOG_DIR: default=$VAR_PREFIX/logs FHS=/var/log/mailman

301

QUEUE_DIR default=$VAR_PREFIX/qfiles FHS=/var/spool/mailman

302

303

304

--

305

John Dennis <jdennis at redhat.com>