linux-ext4 - Re: [PATCH 2/2] ext4: add ext4_iget_normal() which is to be used for dir tree lookups

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]

Message-ID: <20141006031604.GB5755@thunk.org>
Date:	Sun, 5 Oct 2014 23:16:04 -0400
From:	Theodore Ts'o <tytso@....edu>
To:	Andreas Dilger <adilger@...ger.ca>
Cc:	Ext4 Developers List <linux-ext4@...r.kernel.org>
Subject: Re: [PATCH 2/2] ext4: add ext4_iget_normal() which is to be used for
 dir tree lookups

On Sun, Oct 05, 2014 at 08:52:38PM -0600, Andreas Dilger wrote:
> On Oct 5, 2014, at 8:48 PM, Theodore Ts'o <tytso@....edu> wrote:
> > If there is a corrupted file system which has directory entries that
> > point at reserved, metadata inodes, prohibit them from being used by
> > treating them the same way we treat Boot Loader inodes --- that is,
> > mark them to be bad inodes.  This prohibits them from being opened,
> > deleted, or modified via chmod, chown, utimes, etc.
> > 
> > In particular, this prevents a corrupted file system which has a
> > directory entry which points at the journal inode from being deleted
> > and being released, after which point Much Hilarity Ensues.
> 
> Wouldn't it be safer to change "ext4_iget()" to have these checks, 
> and add an "ext4_iget_special()" or "ext4_iget_reserved()" for use
> in the few places that are opening reserved inodes?  That would
> probably be safer for the future.

There is actually much larger set of places where we iget reserved
inodes -- in fact, double the he number of places where we return
inodes back up to the VFS --- 3 for the latter, and 6 for the former.

As for future additions, it's much more likely that we would be adding
new code paths to read reserved inodes.  New VFS functionality tends
to go through the dcache layer, so I don't see the likelihood of
needing to add a new call to ext4_iget_normal() any time soon.

Cheers,

						- 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