> 1) This method of handling recursive nodump is far superior to any actual
> inheritence of the flag as part of file system operations, as currently
> no other file flags are inherited from the parent directory -- the only
> property that is inherited is the group. With ACLs, the parent's
> default ACL will also play a role in the new access ACL. In any case,
> there is no precedent for file flag inheritence.
I'm not sure if this is supposed to be a confirmation, but, just to
clear things up, the patch doesn't cause the nodump flag to be
inherited in the filesystem per se. I.e., you won't see entire trees
of files marked nodump that weren't marked before after running dump
with this patch applied. It is inherited in terms of dump's internal
maps; perhaps propagated would be a better word to describe its
behavior.
>
> 2) Please run the patch by freebsd-audit -- there have been a fair number
> of vulnerabilities in the fts code in the past due to race conditions
> of various sorts, and it's important that any modifications be
> carefully scrutinized to prevent the reintroduction of vulnerabilites.
dump doesn't use fts; I used calling fts_set as an example because in
a program that uses fts, pruning a directory and everything under it
is a matter of one library call. In dump's case, it's not that
simple.
Nevertheless (or should that be consequently?), your point is well
taken. I will send this to -audit in a few days barring any
objections here.
Thanks again
Dima Dorfman
[EMAIL PROTECTED]
>
> However, the general idea sounds very useful, and something that I'd find
> applicable on a daily basis :-).
>
> Robert N M Watson FreeBSD Core Team, TrustedBSD Project
> [EMAIL PROTECTED] NAI Labs, Safeport Network Services
>
> On Mon, 26 Feb 2001, Dima Dorfman wrote:
>
> > Hello -hackers
> >
> > Some time ago, on -arch, phk proposed that the nodump flag should be
> > inherited (see 'inheriting the "nodump" flag ?' around Dec. 2000).
> > This was generally considered a good idea, however, the patch to the
> > kernel he proposed was thought an ugly hack. In addition, jeroen
> > pointed out that NetBSD had implemented this functionality the Right
> > Way(tm), in dump(8).
> >
> > Attached below is a port of NetBSD's patch to FreeBSD's dump(8).
> > dump's tree walker is a little weird, so the patch is a little more
> > complicated than calling fts_set with FTS_SKIP. For the technical
> > details of what it does, see:
> > http://lists.openresources.com/NetBSD/tech-kern/msg00453.html.
> >
> > I've been using this on two of my hosts for a while, and it works as
> > expected. Given the additional fact that NetBSD has had this for
> > almost two years, and that the patch below looks very similar to the
> > one they applied, I doubt it significantly breaks anything.
> >
> > Comments?
> >
> > Thanks in advance
> >
> > Dima Dorfman
> > [EMAIL PROTECTED]
> >
> >
> > [ Patch snipped to conserve bandwidth of those who have to pay for
> > it; it's available at
> > http://www.unixfreak.org/~dima/home/nodump.diff or the mailing
> > list archives if you're interested. ]
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-hackers" in the body of the message
