From owner-freebsd-hackers@FreeBSD.ORG Tue Mar 6 21:04:44 2012 Return-Path: Delivered-To: hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 3DB661065674 for ; Tue, 6 Mar 2012 21:04:44 +0000 (UTC) (envelope-from david@catwhisker.org) Received: from albert.catwhisker.org (m209-73.dsl.rawbw.com [198.144.209.73]) by mx1.freebsd.org (Postfix) with ESMTP id 182FA8FC14 for ; Tue, 6 Mar 2012 21:04:43 +0000 (UTC) Received: from albert.catwhisker.org (localhost [127.0.0.1]) by albert.catwhisker.org (8.14.5/8.14.5) with ESMTP id q26Kf1VC011151 for ; Tue, 6 Mar 2012 12:41:01 -0800 (PST) (envelope-from david@albert.catwhisker.org) Received: (from david@localhost) by albert.catwhisker.org (8.14.5/8.14.5/Submit) id q26Kf1OL011150 for hackers@freebsd.org; Tue, 6 Mar 2012 12:41:01 -0800 (PST) (envelope-from david) Date: Tue, 6 Mar 2012 12:41:01 -0800 From: David Wolfskill To: hackers@freebsd.org Message-ID: <20120306204101.GE1730@albert.catwhisker.org> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="lkTb+7nhmha7W+c3" Content-Disposition: inline User-Agent: Mutt/1.4.2.3i Cc: Subject: mtree(8) reporting of file modes X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 06 Mar 2012 21:04:44 -0000 --lkTb+7nhmha7W+c3 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable As I mentioned in , at work, we're trying to use mtree(8) to do reality checks on server configuration/provisioning. (We are not proposing the use of mtree to actually enforce a particular configuration -- we are only considering using it to generate specification files, then check aa given system against those specification files.) I had thought it odd (after running "mtree -c") that most of the entries in the resulting specification file failed to mention the mode of the file; this was the catalyst for the above-cited message. In the mean time, I started poking at the sources. Caveat: I'm not really a C programmer; the bulk of my background is in sysadmin-type positions (though I've been doing other stuff for the last 4 years). Anyway, I fairly quickly focused my attention on src/usr.sbin/mtree/create.c, in particular, on the statf() function therein. Most of this part of the code is barely changed since 4.4 Lite; the most recent change to the section in question (lines 207 - 208 from the version in head as of r232599) was made by rgrimes@ back in 1994. So I presume that there's something I'm overlooking or otherwise missing, since the folks who have been here before were certainly more clueful than I am. But the code in question: =2E.. 206 } 207 if (keys & F_MODE && (p->fts_statp->st_mode & MBITS) !=3D mode) 208 output(indent, &offset, "mode=3D%#o", p->fts_statp->st_= mode & MBITS); =2E.. is what outputs the "mode" to standard output. Here is (the bulk of) what I found: * The "keys & F_MODE" term merely tests to see if we are interested in reporting the file mode. (By default, we are.) * "p->fts_statp->st_mode" refers to the "st_mode" returned from stat() for the file presently being examined. * MBITS is a mask of "mode bits" about which we care; it is defined (in mtree.h) as "(S_ISUID|S_ISGID|S_ISTXT|S_IRWXU|S_IRWXG|S_IRWXO)". These are defined in sys/stat.h; MBITS, thus, works out to 0007777. * mode is set to the (masked) mode of the (immediately) enclosing directory when it is visited in pre-order. (This is done in statd().) As a result, we only report the mode of a file if it differs from the mode of its parent directory. Huh??!? Maybe I'm confused, but certainly for my present purposes, and likely in general, I'd think it would make sense to just always report the file mode. A way to do that would be to change the above excerpt to read: =2E.. 206 } 207 if (keys & F_MODE) 208 output(indent, &offset, "mode=3D%#o", p->fts_statp->st_= mode & MBITS); =2E.. Another alternative, in case there are use cases for the existing behavior, would be to provide either another "key" or a command-line flag that says "give me all the modes". Am I the only one who would find such a change useful? Thanks for any reality checks. :-} Peace, david --=20 David H. Wolfskill david@catwhisker.org Depriving a girl or boy of an opportunity for education is evil. See http://www.catwhisker.org/~david/publickey.gpg for my public key. --lkTb+7nhmha7W+c3 Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.18 (FreeBSD) iEYEARECAAYFAk9Wdl0ACgkQmprOCmdXAD3ewQCfX1YiMhzzyQXg8vWEJPecCmjN z4MAn32q7QepxBonz3TSBcmWwB7shLqR =teo8 -----END PGP SIGNATURE----- --lkTb+7nhmha7W+c3--