From owner-freebsd-hackers@FreeBSD.ORG Tue Mar 6 21:36:20 2012 Return-Path: Delivered-To: hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 5A62E106566B for ; Tue, 6 Mar 2012 21:36:20 +0000 (UTC) (envelope-from freebsd@damnhippie.dyndns.org) Received: from qmta05.emeryville.ca.mail.comcast.net (qmta05.emeryville.ca.mail.comcast.net [76.96.30.48]) by mx1.freebsd.org (Postfix) with ESMTP id 414168FC0C for ; Tue, 6 Mar 2012 21:36:20 +0000 (UTC) Received: from omta19.emeryville.ca.mail.comcast.net ([76.96.30.76]) by qmta05.emeryville.ca.mail.comcast.net with comcast id iM6Z1i0051eYJf8A5MP4L4; Tue, 06 Mar 2012 21:23:04 +0000 Received: from damnhippie.dyndns.org ([24.8.232.202]) by omta19.emeryville.ca.mail.comcast.net with comcast id iMP21i01h4NgCEG01MP3hS; Tue, 06 Mar 2012 21:23:03 +0000 Received: from [172.22.42.240] (revolution.hippie.lan [172.22.42.240]) by damnhippie.dyndns.org (8.14.3/8.14.3) with ESMTP id q26LMxq2015311; Tue, 6 Mar 2012 14:22:59 -0700 (MST) (envelope-from freebsd@damnhippie.dyndns.org) From: Ian Lepore To: David Wolfskill In-Reply-To: <20120306204101.GE1730@albert.catwhisker.org> References: <20120306204101.GE1730@albert.catwhisker.org> Content-Type: text/plain; charset="us-ascii" Date: Tue, 06 Mar 2012 14:22:59 -0700 Message-ID: <1331068979.32194.14.camel@revolution.hippie.lan> Mime-Version: 1.0 X-Mailer: Evolution 2.32.1 FreeBSD GNOME Team Port Content-Transfer-Encoding: 7bit Cc: hackers@freebsd.org Subject: Re: 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:36:20 -0000 On Tue, 2012-03-06 at 12:41 -0800, David Wolfskill wrote: > 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: > > ... > 206 } > 207 if (keys & F_MODE && (p->fts_statp->st_mode & MBITS) != mode) > 208 output(indent, &offset, "mode=%#o", p->fts_statp->st_mode & MBITS); > ... > > 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: > > ... > 206 } > 207 if (keys & F_MODE) > 208 output(indent, &offset, "mode=%#o", p->fts_statp->st_mode & MBITS); > ... > > > 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 At a glance I think the idea here is that when it outputs the directory entry it outputs a /set line that has the directory's mode in it, and then as it does the files in that directory it only needs to output a mode= clause for a file if it differs from the most recent /set line. (This is based on studying the code for about 30 seconds, so don't take it as gospel.) -- Ian