Alejandro Imass <aim...@yabarana.com> wrote: > On Sat, Apr 28, 2012 at 11:39 AM, Robert Bonomi > <bon...@mail.r-bonomi.com> wrote: > > Alejandro Imass <aim...@yabarana.com> wrote: > >> After a little more research, ___it it NOT unlikely at all___ that > >> under high distress and a hard boot, UFS could have somehow corrupted > >> the directory structure, whilst maintaining the data intact. > > > > This is techically accurate, *BUT* the specifics of the quote "corruption" > > unquote in the case under discussion make it *EXTREMELY* unlikely that this > > is what happened. > > > > 99.99+++% of all UFS filesystem "corruption' issues are the result of a > > system crash _between_ the time cached 'meta-data' is updated in memory > > and that data is flushed to disk (a deferred write). > > > > The second most common (and vanishingly rare) failure mode is a powerfail > > _as_ a sector of disk is being written -- resulting in 'garbage data' > > being written to disk. > > > > The next possibility is 'cosmic rays'. If running on 'cheap' hardware > > (i.e., without 'ECC' memory), this can cause a *SINGLE-BIT* error in > > data being output. > > > > The fact that the 'corrupted' filesystem passed fsck -without- any reported > > errors shows that everything in the filesystem meta-data was consistent > > > [...] > > > I think it is safe to conclude that the probabilities -greatly- favor > > alternative #1. > > > > OK. So after your comments and further research I concur with you on > the mv but if it wasn't a human, then this might be exposing a serious > security flaw in the jail system or the way EzJail implements it.
BOGON ALERT!!! Jails only prevent stuff -inside- the jail from affecting stuff outside the jail. They do *NOT* prevent stuff 'oustide the jail' from affecting stuff INSIDE the jail. "For any fool-proof system, there exists a *sufficiently*determined* fool capable of breaking it." > The > whole point of using jails is to protect things like this from > happening. FALSE TO FACT. > Given that the only jail that survived was the front-end > Apache Web server/reverse proxy, then it is also safe to suspect the > apache (or other) process running on it was able to perform a mv of > the rest of the jails to it's own /usr/local/etc/apache22 directory. FALSE TO FACT. > Is there no possibility is that after the system crash, the journal > recocery process and/or fsck could have moved this directories ? "Anything is 'possible'" -- c.f. 'nasal monkeys'. HOWEVER, if, for example, you would bother to examine the source code for fsck you would discover that it doesn't do -anything- 'significant' without ASKING FIRST. You reported it didn't find any problems -- not even anay of the 'petty' ones it will correct w/o asking -if- the '-p' option is specified. "Journal revovery" _could_, 'theoretically' have done it -- *IF* "something else" did the 'mv' just before the crash, and that operation was journaled, but not yet committed to disk at the time of the crash. However, on a standard UFS filesystem, filesystem metadata updates are written 'synchronously', which should eliminate _that_ wild, unfounded, speculaction. "You sir, don't know what you don't know, and much of what you "think" you know is incorrect." _______________________________________________ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to "freebsd-questions-unsubscr...@freebsd.org"
