1 .\" Copyright (c) 1989, 1990, 1993
2 .\" The Regents of the University of California. All rights reserved.
4 .\" Redistribution and use in source and binary forms, with or without
5 .\" modification, are permitted provided that the following conditions
7 .\" 1. Redistributions of source code must retain the above copyright
8 .\" notice, this list of conditions and the following disclaimer.
9 .\" 2. Redistributions in binary form must reproduce the above copyright
10 .\" notice, this list of conditions and the following disclaimer in the
11 .\" documentation and/or other materials provided with the distribution.
12 .\" 4. Neither the name of the University nor the names of its contributors
13 .\" may be used to endorse or promote products derived from this software
14 .\" without specific prior written permission.
16 .\" THIS SOFTWARE IS PROVIDED BY THE REGENTS AND CONTRIBUTORS ``AS IS'' AND
17 .\" ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE
18 .\" IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE
19 .\" ARE DISCLAIMED. IN NO EVENT SHALL THE REGENTS OR CONTRIBUTORS BE LIABLE
20 .\" FOR ANY DIRECT, INDIRECT, INCIDENTAL, SPECIAL, EXEMPLARY, OR CONSEQUENTIAL
21 .\" DAMAGES (INCLUDING, BUT NOT LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS
22 .\" OR SERVICES; LOSS OF USE, DATA, OR PROFITS; OR BUSINESS INTERRUPTION)
23 .\" HOWEVER CAUSED AND ON ANY THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT
24 .\" LIABILITY, OR TORT (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY
25 .\" OUT OF THE USE OF THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF
28 .\" From: @(#)mtree.8 8.2 (Berkeley) 12/11/93
29 .\" $FreeBSD: src/usr.sbin/mtree/mtree.8,v 1.16.2.11 2003/03/11 22:31:29 trhodes Exp $
30 .\" $DragonFly: src/usr.sbin/mtree/mtree.8,v 1.6 2007/10/20 13:43:00 swildner Exp $
37 .Nd map a directory hierarchy
57 .Op Fl X Ar exclude-list
62 utility compares the file hierarchy rooted in the current directory against a
63 specification read from the standard input.
64 Messages are written to the standard output for any files whose
65 characteristics do not match the specifications, or which are
66 missing from either the file hierarchy or the specification.
68 The options are as follows:
71 Follow all symbolic links in the file hierarchy.
73 Don't follow symbolic links in the file hierarchy, instead consider
74 the symbolic link itself in any comparisons. This is the default.
76 Modify the owner, group and permissions of existing files to match
77 the specification and create any missing directories or symbolic links.
78 User, group and permissions must all be specified for missing directories
80 Corrected mismatches are not considered errors.
82 Print a specification for the file hierarchy to the standard output.
84 Ignore everything except directory type files.
86 Don't complain about files that are in the file hierarchy, but not in the
89 Indent the output 4 spaces each time a directory level is descended when
90 create a specification with the
93 This does not affect either the /set statements or the comment before each
95 It does however affect the comment before the close of each directory.
97 Do not emit pathname comments when creating a specification. Normally
98 a comment is emitted before each directory and before the close of that
99 directory when using the
103 Quiet mode. Do not complain when a
105 directory cannot be created because it already exists.
106 This occurs when the directory is a symbolic link.
108 Remove any files in the file hierarchy that are not described in the
113 except a status of 2 is returned if the file hierarchy did not match
116 Don't descend below mount points in the file hierarchy.
118 Read the specification from
120 instead of from the standard input.
122 Add the specified (whitespace or comma separated)
124 to the current set of keywords.
126 Use the ``type'' keyword plus the specified (whitespace or comma separated)
128 instead of the current set of keywords.
130 Use the file hierarchy rooted in
132 instead of the current directory.
134 Display a single checksum to the standard error output that represents all
135 of the files for which the keyword
138 The checksum is seeded with the specified value.
139 .It Fl X Ar exclude-list
140 The specified file contains
142 patterns matching files to be excluded from
143 the specification, one to a line.
144 If the pattern contains a
146 character, it will be matched against entire pathnames (relative to
147 the starting directory); otherwise,
148 it will be matched against basenames only. No comments are allowed in
154 Specifications are mostly composed of ``keywords'', i.e. strings
155 that specify values relating to files.
156 No keywords have default values, and if a keyword has no value set, no
157 checks based on it are performed.
159 Currently supported keywords are as follows:
162 The checksum of the file using the default algorithm specified by
167 The file flags as a symbolic name. See
169 for information on these names. If no flags are to be set the string
171 may be used to override the current default.
173 Ignore any file hierarchy below this file.
175 The file group as a numeric value.
177 The file group as a symbolic name.
179 The MD5 message digest of the file.
185 message digest of the file.
186 .It Cm ripemd160digest
189 message digest of the file.
191 The current file's permissions as a numeric (octal) or symbolic
194 The number of hard links the file is expected to have.
196 Make sure this file or directory exists but otherwise ignore all attributes.
198 The file owner as a numeric value.
200 The file owner as a symbolic name.
202 The size, in bytes, of the file.
204 The file the symbolic link is expected to reference.
206 The last modification time of the file.
208 The type of the file; may be set to any one of the following:
210 .Bl -tag -width Cm -compact
214 character special device
228 The default set of keywords are
239 There are four types of lines in a specification.
241 The first type of line sets a global value for a keyword, and consists of
242 the string ``/set'' followed by whitespace, followed by sets of keyword/value
243 pairs, separated by whitespace.
244 Keyword/value pairs consist of a keyword, followed by an equals sign
245 (``=''), followed by a value, without whitespace characters.
246 Once a keyword has been set, its value remains unchanged until either
249 The second type of line unsets keywords and consists of the string
250 ``/unset'', followed by whitespace, followed by one or more keywords,
251 separated by whitespace.
253 The third type of line is a file specification and consists of a file
254 name, followed by whitespace, followed by zero or more whitespace
255 separated keyword/value pairs.
256 The file name may be preceded by whitespace characters.
257 The file name may contain any of the standard file name matching
258 characters (``['', ``]'', ``?'' or ``*''), in which case files
259 in the hierarchy will be associated with the first pattern that
262 Each of the keyword/value pairs consist of a keyword, followed by an
263 equals sign (``=''), followed by the keyword's value, without
264 whitespace characters.
265 These values override, without changing, the global value of the
266 corresponding keyword.
268 All paths are relative.
269 Specifying a directory will cause subsequent files to be searched
270 for in that directory hierarchy.
271 Which brings us to the last type of line in a specification: a line
272 containing only the string
274 causes the current directory
275 path to ascend one level.
277 Empty lines and lines whose first non-whitespace character is a hash
278 mark (``#'') are ignored.
282 utility exits with a status of 0 on success, 1 if any error occurred,
283 and 2 if the file hierarchy did not match the specification.
284 A status of 2 is converted to a status of 0 if the
288 .Bl -tag -width /etc/mtree -compact
290 system specification directory
295 To detect system binaries that have been ``trojan horsed'', it is recommended
300 be run on the file systems, and a copy of the results stored on a different
301 machine, or, at least, in encrypted form.
302 The output file itself should be digested using the
309 should be run against the on-line specifications.
310 While it is possible for the bad guys to change the on-line specifications
311 to conform to their modified binaries, it is believed to be
312 impractical for them to create a modified specification which has
313 the same MD5 digest as the original.
319 options can be used in combination to create directory hierarchies
320 for distributions and other such things; the files in
322 were used to create almost all directories in this
328 style BSD.*.dist file, use
335 .Cm uname,gname,mode,nochange .
353 digest capability was added in
355 in response to the widespread use of programs which can spoof
361 digests were added in
363 as new attacks have demonstrated weaknesses in
365 Support for file flags was added in
367 and mostly comes from