MTREE(8) | System Manager's Manual | MTREE(8) |
mtree
— map a
directory hierarchy
mtree |
[-LPUcdeinqruVwx ]
[-f spec]
[-I include-list]
[-K keywords]
[-k keywords]
[-p path]
[-s seed]
[-X exclude-list] |
The mtree
utility compares the file
hierarchy rooted in the current directory against a specification read from
the standard input. Messages are written to the standard output for any
files whose characteristics do not match the specifications, or which are
missing from either the file hierarchy or the specification.
The options are as follows:
-L
-P
-U
-c
-d
-e
-i
-c
option. This
does not affect either the /set statements or the comment before each
directory. It does however affect the comment before the close of each
directory.-n
-c
option.-q
-r
-u
-U
except a status of 2 is returned if the
file hierarchy did not match the specification.-w
-x
-f
fileIf this option is specified twice, the two specifications are
compared to each other rather than to the file hierarchy. The
specifications will be sorted like output generated using
-c
. The output format in this case is somewhat
remniscent of comm(1), having "in
first spec only", "in second spec only", and
"different" columns, prefixed by zero, one and two TAB
characters respectively. Each entry in the "different" column
occupies two lines, one from each specification.
-I
include-list/
’
character, it will be matched against entire pathnames (relative to the
starting directory); otherwise, it will be matched against basenames only.
No comments are allowed in the include-list file.
If this flag is not present, all files are included by default.
-K
keywords-k
keywords-p
path-r
-s
seedcksum
was
specified. The checksum is seeded with the specified value.-V
-r
is specified, also recursively remove
non-empty directories.-X
exclude-list/
’
character, it will be matched against entire pathnames (relative to the
starting directory); otherwise, it will be matched against basenames only.
No comments are allowed in the exclude-list file.
If both -I
and
-X
are specified, any files matching both lists
are excluded.
Specifications are mostly composed of ``keywords'', i.e., strings that specify values relating to files. No keywords have default values, and if a keyword has no value set, no checks based on it are performed.
Currently supported keywords are as follows:
cksum
flags
ignore
gid
gname
md5digest
sha1digest
sha256digest
ripemd160digest
mode
nlink
nochange
optional
uid
uname
size
link
time
type
The default set of keywords are flags
,
gid
, mode
,
nlink
, size
,
link
, time
, and
uid
.
There are four types of lines in a specification.
The first type of line sets a global value for a keyword, and consists of the string ``/set'' followed by whitespace, followed by sets of keyword/value pairs, separated by whitespace. Keyword/value pairs consist of a keyword, followed by an equals sign (``=''), followed by a value, without whitespace characters. Once a keyword has been set, its value remains unchanged until either reset or unset.
The second type of line unsets keywords and consists of the string ``/unset'', followed by whitespace, followed by one or more keywords, separated by whitespace.
The third type of line is a file specification and consists of a file name, followed by whitespace, followed by zero or more whitespace separated keyword/value pairs. The file name may be preceded by whitespace characters. The file name may contain any of the standard file name matching characters (``['', ``]'', ``?'' or ``*''), in which case files in the hierarchy will be associated with the first pattern that they match.
Each of the keyword/value pairs consist of a keyword, followed by an equals sign (``=''), followed by the keyword's value, without whitespace characters. These values override, without changing, the global value of the corresponding keyword.
All paths are relative. Specifying a directory will cause subsequent files to be searched for in that directory hierarchy. Which brings us to the last type of line in a specification: a line containing only the string “..” causes the current directory path to ascend one level.
Empty lines and lines whose first non-whitespace character is a hash mark (``#'') are ignored.
The mtree
utility exits with a status of 0
on success, 1 if any error occurred, and 2 if the file hierarchy did not
match the specification. A status of 2 is converted to a status of 0 if the
-U
option is used.
The mtree
utility exits 0 on
success, and >0 if an error occurs.
To detect system binaries that have been ``trojan horsed'', it is
recommended that mtree
-K
sha256digest
be run on the file systems, and a copy
of the results stored on a different machine, or, at least, in encrypted
form. The output file itself should be digested using the
sha256(1) utility. Then, periodically,
mtree
and
sha256(1) should be run against the
on-line specifications. While it is possible for the bad guys to change the
on-line specifications to conform to their modified binaries, it is believed
to be impractical for them to create a modified specification which has the
same SHA-256 digest as the original.
The -d
and -u
options can be used in combination to create directory hierarchies for
distributions and other such things; the files in
/etc/mtree were used to create almost all
directories in this FreeBSD distribution.
To create an /etc/mtree style BSD.*.dist
file, use mtree
-c
-d
-i
-n
-k
uname,gname,mode,nochange.
chflags(1), chgrp(1), chmod(1), cksum(1), md5(1), stat(2), fts(3), md5(3), chown(8)
mtree-port: Utility for creating and verifying file hierarchies, https://github.com/archiecobbs/mtree-port.
The mtree
utility appeared in
4.3BSD-Reno. The MD5 digest capability was added in
FreeBSD 2.1, in response to the widespread use of
programs which can spoof cksum(1). The
SHA-1 and RIPEMD160 digests were added in FreeBSD
4.0, as new attacks have demonstrated weaknesses in MD5. The SHA-256
digest was added in FreeBSD 6.0. Support for file
flags was added in FreeBSD 4.0, and mostly comes
from NetBSD.
mtree
was ported to Linux by
Archie L. Cobbs
⟨archie@dellroad.org⟩
June 16, 2007 | x86_64 |