linux-ext4 - Re: [PATCH] e2fsprogs - pass1c terminates early if hard links

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Date:	Wed, 11 Apr 2007 08:57:07 -0400
From:	Theodore Tso <tytso@....edu>
To:	Andreas Dilger <adilger@...sterfs.com>
Cc:	Jim Garlick <garlick@...l.gov>, linux-ext4@...r.kernel.org
Subject: Re: [PATCH] e2fsprogs - pass1c terminates early if hard links

On Wed, Apr 11, 2007 at 05:51:47AM -0600, Andreas Dilger wrote:
> > Of course the temptation then would be to start adding conditions,
> > functions, maybe an entire tcl interpreter....   :-)
> 
> Yes, I thought of this too, and also the "let's build a full interpreted
> language into debugfs" conclusion.  It wouldn't be fatal though - in
> some cases it would be nice to have debugfs loop over inodes to fix some
> unusual corruption.

I have actually thought about the possibility of extending libss so
that it would optionally load the tcl shared library, just as today we
optionally load the readline library.  The interfaces used by libss to
call individual command handlers and those used by tcl aren't actually
all that different.

If someone wanted to look into it, patches would certainly be
gratefully accepted.  Having the ability to loop over inodes would
come in handy, and while you can do it to day by writing the script in
perl or bash and then using debugfs -R, (1) it's clumsy, and (2) it's
slow for big filesystems if you have to read the bitmaps each time.

Speaking of which, wasn't someone going to write patches that did lazy
bitmap loading for debugfs?  I can't remember who said they would do
that.  To whoever was going to do that --- one thought which I had ---
it would probably be a good idea to keep the current catastrophic
mode, and change it so that in catatrophic mode, bitmaps are not
loaded automatically, and an error message is returned right away.
There may be situations where you don't want debugfs to ever even try
loading the bitmaps (because they will fail after waiting a long
time), and so an immediate refusal to execute a particular command
requires the bitmaps to be loaded may be preferable.

						- Ted

-
To unsubscribe from this list: send the line "unsubscribe linux-ext4" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html