linux-ext4 - Re: [PATCH][7/28] e2fsprogs-extents.patch

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: <47B9EF12.5020400@redhat.com>
Date:	Mon, 18 Feb 2008 14:48:18 -0600
From:	Eric Sandeen <sandeen@...hat.com>
To:	Theodore Tso <tytso@....edu>
CC:	Andreas Dilger <adilger@....com>, linux-ext4@...r.kernel.org
Subject: Re: [PATCH][7/28] e2fsprogs-extents.patch

Theodore Tso wrote:
> On Mon, Feb 18, 2008 at 11:56:53AM -0600, Eric Sandeen wrote:
>> So this trips up on things like sockets, fifos, and block & char nodes.
>>
>> Also this is unhappy:
>>
>>> @@ -137,7 +141,7 @@ int e2fsck_pass1_check_device_inode(ext2
>>>  	 * If the index flag is set, then this is a bogus
>>>  	 * device/fifo/socket
>>>  	 */
>>> -	if (inode->i_flags & EXT2_INDEX_FL)
>>> +	if (inode->i_flags & (EXT2_INDEX_FL | EXT4_EXTENTS_FL))
>>>  		return 0;
>> Do we really care if these have the extents flag set?  IOW should we
>> make sure the kernel doesn't set the flag, or should we make e2fsck not
>> care...
> 
> <Sigh>
> 
> I think we need to get kernel patches into mainline ASAP not to set
> the EXTENTS_FL 

You mean on devices/fifos/sockets ?  Ok.

But today, with 2.6.25-rc1 and e2fsprogs-interim, long (non-fast)
symlinks get clobbered by e2fsck, because:

Pass 1: Checking inodes, blocks, and sizes
Inode 12 has EXTENT_FL set, but is not in extents format
Fix? yes

Inode 12 has illegal block(s).  Clear? yes

Illegal block #0 (127754) in inode 12.  CLEARED.
Inode 12 is too big.  Truncate? yes

Block #1 (4) causes symlink to be too big.  CLEARED.
Block #4 (1) causes symlink to be too big.  CLEARED.
Block #5 (4772) causes symlink to be too big.  CLEARED.
Inode 12, i_blocks is 2, should be 0.  Fix? yes

Pass 2: Checking directory structure
Symlink /longlink (inode #12) is invalid.
Clear? yes

Pass 3: Checking directory connectivity
Pass 4: Checking reference counts
Pass 5: Checking group summary information
Block bitmap differences:  -4772
Fix? yes

Free blocks count wrong for group #0 (3420, counted=3421).
Fix? yes

Free blocks count wrong (26192, counted=26193).
Fix? yes

and *poof* it's gone.  That one concerns me more...  This *should* be in
extents format, right, even though it's limited to one block...

> and at least
> for now, e2fsck needs to accept (and not complain or core dump) if
> EXTENTS_FL is set for files where ext2fs_inode_has_valid_blocks()
> returns false

well, if any filetypes are not supposed to have the extents flag set,
and they're zero-length, I'd say go ahead & clear it, and even complain
if you like - it's the design intent after all -  I wouldn't worry about
the noise at this stage.  FWIW, I haven't seen a core dump.  :)

-Eric
-
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