Re: [Bug 9855] ext3 ACL corruption

Re: [Bug 9855] ext3 ACL corruption

[Kevin Shanahan]

[-- Attachment #1: Type: text/plain, Size: 1956 bytes --]

On Thu, 2008-01-31 at 03:05 -0700, Andreas Dilger wrote:
> ...  To get the interesting bits you need:
> 
> debugfs: stat <966665>   # prints decoded inode, "File ACL:" is a block number
> debugfs: imap <966665>   # prints inode block number, offset
> 
> dd if=/dev/mapper/vg_main-lv_samba of=/tmp/inode.bin bs=4k count=1 skip={iblock}
> dd if=/dev/mapper/vg_main-lv_samba of=/tmp/inode.bin bs=4k count=1 skip={ACLblk}

Ah, ok - learning fast. Lets see how I go this time:

e2fsck 1.40-WIP (14-Nov-2006)
Pass 1: Checking inodes, blocks, and sizes
(entry->e_value_offs + entry->e_value_size: 116, offs: 120)
Extended attribute in inode 3342652 has a value offset (72) which is
invalid
Clear? no
...

# debugfs /dev/mapper/vg_main-lv_samba
debugfs:  stat <3342652>

Inode: 3342652   Type: regular    Mode:  0770   Flags: 0x0   Generation: 3684645243
User:     0   Group: 10140   Size: 18432
File ACL: 0    Directory ACL: 0
Links: 1   Blockcount: 40
Fragment:  Address: 0    Number: 0    Size: 0
ctime: 0x475be06e -- Sun Dec  9 23:02:46 2007
atime: 0x475d4073 -- Tue Dec 11 00:04:43 2007
mtime: 0x45d2686a -- Wed Feb 14 12:09:54 2007
Size of extra inode fields: 4
Extended attributes stored in inode body: 
   = "01 00 00 00 01 00 07 00 04 00 05 00 08 00 05 00 d6 27 00 00 08 00 07 00 09 28 00 00 08 00 07 00 0a 28 00 00 10 00 07 00 20 00 00 00 " (44)
  DOSATTRIB = "0x20" (4)
BLOCKS:
(0):6713397, (1):6713399, (2):6713395, (3):6713405, (4):6713396
TOTAL: 5

debugfs:  imap <3342652>
Inode 3342652 is part of block group 204
      located at block 6684693, offset 0x0b00

# dd if=/dev/mapper/vg_main-lv_samba of=iblock.bin bs=4k count=1 skip=6684693
1+0 records in
1+0 records out
4096 bytes (4.1 kB) copied, 0.000429132 seconds, 9.5 MB/s

I'm assuming that "File ACL: 0" means that there's no ACL block.

> Attach all of the above to an email to the list...  It will only be 8 kB.

Ok, done. Hopefully this is what you mean by "the list". :)

Cheers,
Kevin.


[-- Attachment #2: iblock.bin --]
[-- Type: application/octet-stream, Size: 4096 bytes --]

Re: [Bug 9855] ext3 ACL corruption

[Andreas Dilger]

On Jan 31, 2008  22:44 +1030, Kevin Shanahan wrote:
> On Thu, 2008-01-31 at 03:05 -0700, Andreas Dilger wrote:
> > ...  To get the interesting bits you need:
> > 
> > debugfs: stat <966665>   # prints decoded inode, "File ACL:" is a block number
> > debugfs: imap <966665>   # prints inode block number, offset
> > 
> > dd if=/dev/mapper/vg_main-lv_samba of=/tmp/inode.bin bs=4k count=1 skip={iblock}
> > dd if=/dev/mapper/vg_main-lv_samba of=/tmp/inode.bin bs=4k count=1 skip={ACLblk}
> 
> Ah, ok - learning fast. Lets see how I go this time:
> 
> # debugfs /dev/mapper/vg_main-lv_samba
> debugfs:  stat <3342652>
> 
> Inode: 3342652   Type: regular    Mode:  0770   Flags: 0x0   Generation: 3684645243
> User:     0   Group: 10140   Size: 18432
> File ACL: 0    Directory ACL: 0
> Links: 1   Blockcount: 40
> Fragment:  Address: 0    Number: 0    Size: 0
> ctime: 0x475be06e -- Sun Dec  9 23:02:46 2007
> atime: 0x475d4073 -- Tue Dec 11 00:04:43 2007
> mtime: 0x45d2686a -- Wed Feb 14 12:09:54 2007
> Size of extra inode fields: 4
> Extended attributes stored in inode body: 
>    = "01 00 00 00 01 00 07 00 04 00 05 00 08 00 05 00 d6 27 00 00 08 00 07 00 09 28 00 00 08 00 07 00 0a 28 00 00 10 00 07 00 20 00 00 00 " (44)
>   DOSATTRIB = "0x20" (4)
> BLOCKS:
> (0):6713397, (1):6713399, (2):6713395, (3):6713405, (4):6713396
> TOTAL: 5
> 
> debugfs:  imap <3342652>
> Inode 3342652 is part of block group 204
>       located at block 6684693, offset 0x0b00

The hexdump of this data (od -Ax -tx4 -a) shows the EA is in good shape:

000b80 00000004        ea020000        00480200        00000000
       eot nul nul nul nul nul stx   j nul stx   H nul nul nul nul nul

inode.i_extra_isize=0x0004
ext3_xattr_ibody_header.h_magic=0xea020000

[EA1 entry]
ext3_xattr_entry.e_name_len=0x00  (unused for POSIX_ACL_ACCESS)
ext3_xattr_entry.e_name_index=0x02 (EXT3_INDEX_POSIX_ACL_ACCESS)
ext3_xattr_entry.e_value_offs=0x0048 = 72
ext3_xattr_entry.e_value_block=0x00000000  (unused)



000b90 0000002c        00000000        00740109        00000000
         , nul nul nul nul nul nul nul  ht soh   t nul nul nul nul nul
[EA1 cont.]
ext3_xattr_entry.e_value_size=0x0000002c = 44
ext3_xattr_entry.e_hash=0x00000000  (currently unused)

[EA2 entry]
ext3_xattr_entry.e_name_len=0x09
ext3_xattr_entry.e_name_index=0x01 (EXT3_INDEX_USER)
ext3_xattr_entry.e_value_offs=0x0074 = 116
ext3_xattr_entry.e_value_block=0x00000000  (unused)

000ba0 00000004        00000000        41534f44        49525454
       eot nul nul nul nul nul nul nul   D   O   S   A   T   T   R   I
[EA2 cont.]
ext3_xattr_entry.e_value_size=0x0000002c = 44
ext3_xattr_entry.e_hash=0x00000000  (currently unused)
ext3_xattr_entry.e_name=DOSATTRIB

000bb0 00000042        00000000        00000000        00000000
         B nul nul nul nul nul nul nul nul nul nul nul nul nul nul nul
000bc0 00000000        00000000        00000000        00000000
       nul nul nul nul nul nul nul nul nul nul nul nul nul nul nul nul

000bd0 00000001        00070001        00050004        00050008
       soh nul nul nul soh nul bel nul eot nul enq nul  bs nul enq nul
[EA1 data]
ext3_acl_header.a_version=0x00000001
ext3_acl_entry_short[0].e_tag=0x0001
ext3_acl_entry_short[0].e_perm=0x0007
ext3_acl_entry_short[1].e_tag=0x0004
ext3_acl_entry_short[1].e_perm=0x0005
ext3_acl_entry_short[2].e_tag=0x0008
ext3_acl_entry_short[2].e_perm=0x0005

000be0 000027d6        00070008        00002809        00070008
         V   ' nul nul  bs nul bel nul  ht   ( nul nul  bs nul bel nul
[EA1 data cont]
ext3_acl_entry_short[2].e_id=0x27d6
ext3_acl_entry[3].e_tag=0x0008
ext3_acl_entry[3].e_perm=0x0007
ext3_acl_entry[3].e_id=0x00002809

ext3_acl_entry[5].e_tag=0x0008
ext3_acl_entry[5].e_perm=0x0007
ext3_acl_entry[5].e_id=0x0000280a

000bf0 0000280a        00070010        00000020        30327830
        nl   ( nul nul dle nul bel nul  sp nul nul nul   0   x   2   0
[EA1 data cont]
ext3_acl_entry[6].e_tag=0x0010
ext3_acl_entry[6].e_perm=0x0007
ext3_acl_entry[6].e_id=0x00000020

[EA2 data]
"0x20"

> I'm assuming that "File ACL: 0" means that there's no ACL block.

Right.

> e2fsck 1.40-WIP (14-Nov-2006)
> Pass 1: Checking inodes, blocks, and sizes
> (entry->e_value_offs + entry->e_value_size: 116, offs: 120)
> Extended attribute in inode 3342652 has a value offset (72) which is
> invalid
> Clear? no
> ...

Hmm, I wonder if e2fsck is calculating the wrong file offset or something?
The kernel appears to be taking the EA data offset from the end of
i_extra_isize and the ext3_xattr_ibody_header fields (so 0x88 + e_value_offs
from the start of the inode).

Conversely, debugfs isn't having any problem with this EA at all.

h, I think I see the problem, and this was fixed in newer e2fsck.
The EAs are stored "out of order" in the inode and older e2fsprogs
considered that an error.  That was fixed in the final 1.40 release:

	Remove check in e2fsck which requires EA's in inodes to be sorted;
	they don't need to be sorted, and e2fsck was previously wrongly
	clearing unsorted EA's stored in the inode structure.


Cheers, Andreas
--
Andreas Dilger
Sr. Staff Engineer, Lustre Group
Sun Microsystems of Canada, Inc.

Re: [Bug 9855] ext3 ACL corruption

[Kevin Shanahan]

On Mon, 2008-02-04 at 18:06 -0700, Andreas Dilger wrote:
> Hmm, I wonder if e2fsck is calculating the wrong file offset or something?
> The kernel appears to be taking the EA data offset from the end of
> i_extra_isize and the ext3_xattr_ibody_header fields (so 0x88 + e_value_offs
> from the start of the inode).
> 
> Conversely, debugfs isn't having any problem with this EA at all.
> 
> h, I think I see the problem, and this was fixed in newer e2fsck.
> The EAs are stored "out of order" in the inode and older e2fsprogs
> considered that an error.  That was fixed in the final 1.40 release:
> 
> 	Remove check in e2fsck which requires EA's in inodes to be sorted;
> 	they don't need to be sorted, and e2fsck was previously wrongly
> 	clearing unsorted EA's stored in the inode structure.

Ah, I think you got it! I've just now reproduced the problem on one
filesystem with the old e2fsck-1.40-WIP from Debian Etch and then
checked again with the newer e2fsck-1.40.5 from Sid. The new version
doesn't report any problems.

Thanks very much for your time looking into this.

Regards,
Kevin.