Bump minor version number (keep in step with the rest of the system)
[unix-history] / usr.sbin / mtree / mtree.8
CommitLineData
4e97a0eb
NW
1.\" Copyright (c) 1989, 1990 The Regents of the University of California.
2.\" All rights reserved.
3.\"
4.\" Redistribution and use in source and binary forms, with or without
5.\" modification, are permitted provided that the following conditions
6.\" are met:
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.\" 3. All advertising materials mentioning features or use of this software
13.\" must display the following acknowledgement:
14.\" This product includes software developed by the University of
15.\" California, Berkeley and its contributors.
16.\" 4. Neither the name of the University nor the names of its contributors
17.\" may be used to endorse or promote products derived from this software
18.\" without specific prior written permission.
19.\"
20.\" THIS SOFTWARE IS PROVIDED BY THE REGENTS AND CONTRIBUTORS ``AS IS'' AND
21.\" ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE
22.\" IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE
23.\" ARE DISCLAIMED. IN NO EVENT SHALL THE REGENTS OR CONTRIBUTORS BE LIABLE
24.\" FOR ANY DIRECT, INDIRECT, INCIDENTAL, SPECIAL, EXEMPLARY, OR CONSEQUENTIAL
25.\" DAMAGES (INCLUDING, BUT NOT LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS
26.\" OR SERVICES; LOSS OF USE, DATA, OR PROFITS; OR BUSINESS INTERRUPTION)
27.\" HOWEVER CAUSED AND ON ANY THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT
28.\" LIABILITY, OR TORT (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY
29.\" OUT OF THE USE OF THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF
30.\" SUCH DAMAGE.
31.\"
32.\" @(#)mtree.8 5.11 (Berkeley) 12/11/91
33.\"
34.Dd December 11, 1991
35.Dt MTREE 8
36.Os
37.Sh NAME
38.Nm mtree
39.Nd map a directory hierarchy
40.Sh SYNOPSIS
41.Nm mtree
42.Op Fl cderux
43.Op Fl f Ar spec
44.Op Fl K Ar keywords
45.Op Fl k Ar keywords
46.Op Fl p Ar path
47.Op Fl s Ar seed
48.Sh DESCRIPTION
49The utility
50.Nm mtree
51compares the file hierarchy rooted in the current directory against a
52specification read from the standard input.
53Messages are written to the standard output for any files whose
54characteristics do not match the specification's, or which are
55missing from either the file hierarchy or the specification.
56.Pp
57The options are as follows:
58.Bl -tag -width flag
59.It Fl c
60Print a specification for the file hierarchy to the standard output.
61.It Fl d
62Ignore everything except directory type files.
63.It Fl e
64Don't complain about files that are in the file hierarchy, but not in the
65specification.
66.It Fl f
67Read the specification from
68.Ar file ,
69instead of from the standard input.
70.It Fl K
71Add the specified (whitespace or comma separated) keywords to the current
72set of keywords.
73.It Fl k
74Use the ``type'' keyword plus the specified (whitespace or comma separated)
75keywords instead of the current set of keywords.
76.It Fl p
77Use the file hierarchy rooted in
78.Ar path ,
79instead of the current directory.
80.It Fl r
81Remove any files in the file hierarchy that are not described in the
82specification.
83.It Fl s
84Display a single checksum to the standard error output that represents all
85of the files for which the keyword
86.Cm cksum
87was specified.
88The checksum is seeded with the specified value.
89.It Fl u
90Modify the owner, group, and permissions of existing files to match
91the specification and create any missing directories.
92User, group, and permissions must all be specified for missing directories
93to be created.
94.It Fl x
95Don't descend below mount points in the file hierarchy.
96.El
97.Pp
98Specifications are mostly composed of ``keywords'', i.e. strings that
99that specify values relating to files.
100No keywords have default values, and if a keyword has no value set, no
101checks based on it are performed.
102.Pp
103Currently supported keywords are as follows:
104.Bl -tag -width Cm
105.It Cm cksum
106The checksum of the file using the default algorithm specified by
107the
108.Xr cksum 1
109utility.
110.It Cm ignore
111Ignore any file hierarchy below this file.
112.It Cm gid
113The file group as a numeric value.
114.It Cm gname
115The file group as a symbolic name.
116.It Cm mode
117The current file's permissions as a numeric (octal) or symbolic
118value.
119.It Cm nlink
120The number of hard links the file is expected to have.
121.It Cm uid
122The file owner as a numeric value.
123.It Cm uname
124The file group as a symbolic name.
125.It Cm size
126The size, in bytes, of the file.
127.It Cm link
128The file the symbolic link is expected to reference.
129.It Cm time
130The last modification time of the file.
131.It Cm type
132The type of the file; may be set to any one of the following:
133.sp
134.Bl -tag -width Cm -compact
135.It Cm block
136block special device
137.It Cm char
138character special device
139.It Cm dir
140directory
141.It Cm fifo
142fifo
143.It Cm file
144regular file
145.It Cm link
146symbolic link
147.It Cm socket
148socket
149.El
150.El
151.Pp
152The default set of keywords are
153.Cm gid ,
154.Cm mode ,
155.Cm nlink ,
156.Cm size ,
157.Cm slink ,
158.Cm time ,
159and
160.Cm uid .
161.Pp
162There are four types of lines in a specification.
163.Pp
164The first type of line sets a global value for a keyword, and consists of
165the string ``/set'' followed by whitespace, followed by sets of keyword/value
166pairs, separated by whitespace.
167Keyword/value pairs consist of a keyword, followed by an equals sign
168(``=''), followed by a value, without whitespace characters.
169Once a keyword has been set, its value remains unchanged until either
170reset or unset.
171.Pp
172The second type of line unsets keywords and consists of the string
173``/unset'', followed by whitespace, followed by one or more keywords,
174separated by whitespace.
175.Pp
176The third type of line is a file specification and consists of a file
177name, followed by whitespace, followed by zero or more whitespace
178separated keyword/value pairs.
179The file name may be preceded by whitespace characters.
180The file name may contain any of the standard file name matching
181characters (``['', ``]'', ``?'' or ``*''), in which case files
182in the hierarchy will be associated with the first pattern that
183they match.
184.Pp
185Each of the keyword/value pairs consist of a keyword, followed by an
186equals sign (``=''), followed by the keyword's value, without
187whitespace characters.
188These values override, without changing, the global value of the
189corresponding keyword.
190.Pp
191All paths are relative.
192Specifying a directory will cause subsequent files to be searched
193for in that directory hierarchy.
194Which brings us to the last type of line in a specification: a line
195containing only the string
196.Dq Nm \&..
197causes the current directory
198path to ascend one level.
199.Pp
200Empty lines and lines whose first non-whitespace character is a hash
201mark (``#'') are ignored.
202.Pp
203The
204.Nm mtree
205utility exits with a status of 0 on success, 1 if any error occurred,
206and 2 if the file hierarchy did not match the specification.
207.Sh EXAMPLES
208To detect system binaries that have been ``trojan horsed'', it is recommended
209that
210.Nm mtree
211be run on the file systems, and a copy of the results stored on a different
212machine, or, at least, in encrypted form.
213The seed for the
214.Fl s
215option should not be an obvious value and the final checksum should not be
216stored on-line under any circumstances!
217Then, periodically,
218.Nm mtree
219should be run against the on-line specifications and the final checksum
220compared with the previous value.
221While it is possible for the bad guys to change the on-line specifications
222to conform to their modified binaries, it shouldn't be possible for them
223to make it produce the same final checksum value.
224If the final checksum value changes, the off-line copies of the specification
225can be used to detect which of the binaries have actually been modified.
226.Pp
227The
228.Fl d
229and
230.Fl u
231options can be used in combination to create directory hierarchies
232for distributions and other such things.
233.Sh FILES
234.Bl -tag -width /etc/mtree -compact
235.It Pa /etc/mtree
236system specification directory
237.El
238.Sh SEE ALSO
239.Xr chmod 1 ,
240.Xr chown 1 ,
241.Xr chgrp 1 ,
242.Xr cksum 1 ,
243.Xr stat 2 ,
244.Xr fts 3 ,
245.Sh HISTORY
246The
247.Nm mtree
248utility appeared in
249.Bx 4.3 Reno .