| 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
| ||
|
Message-ID: <20130904053503.GA3518@gmail.com>
Date: Wed, 4 Sep 2013 13:35:03 +0800
From: Zheng Liu <gnehzuil.liu@...il.com>
To: Felipe Monteiro de Carvalho <felipemonteiro.carvalho@...il.com>
Cc: Theodore Ts'o <tytso@....edu>, linux-ext4@...r.kernel.org
Subject: Re: Which features should I implement in my ext4 reader?
On Mon, Sep 02, 2013 at 02:35:31PM +0200, Felipe Monteiro de Carvalho wrote:
> Hello,
>
> Ok, I think I got it almost finished =) Just 1 last wierd thing. I
> dumped my inode and I found that when the extended attribute is in the
> space after the inode, then the attribute data starts 3 bytes before
> the end of this area! But in the wiki nothing is said about this. It
> was supposed to start at the end of the section ... not 3 bytes before
> the end of the section
>
> Here are the 3 zeroes in the end:
>
> 7760 4444 4444 4444 4444 4444 4444 0a00 0000 DDDDDDDDDDDD....
>
> Any idea what are those 3 zeroes in the end? I simply hardcoded in my
> application that there exists 3 zeroes in the end, but its really
> strange as this does not make any sense to waste 3 bytes and I didn't
> see any such a thing in the wiki nor the xattr.h header...
>
> Also wierd: This 3 last bytes do no appear when extended attributes
> are stored in a separate block.
Could you please tell me how to reproduce this problem? I try to create
a file with inline data, but I couldn't reproduce your problem.
Thanks,
- Zheng
>
> Full set of dumps:
>
> debugfs: stat smallfile120.txt
> Inode: 16 Type: regular Mode: 0644 Flags: 0x10000000
> Generation: 230499867 Version: 0x00000000:00000001
> User: 0 Group: 0 Size: 121
> File ACL: 0 Directory ACL: 0
> Links: 1 Blockcount: 0
> Fragment: Address: 0 Number: 0 Size: 0
> ctime: 0x52149464:04e2df1c -- Wed Aug 21 06:20:20 2013
> atime: 0x52177658:c0a4e548 -- Fri Aug 23 10:48:56 2013
> mtime: 0x52149464:04e2df1c -- Wed Aug 21 06:20:20 2013
> crtime: 0x52149464:04e2df1c -- Wed Aug 21 06:20:20 2013
> Size of extra inode fields: 28
> Extended attributes stored in inode body:
> data = "CCCCCCCCCCCCCCCCCCCCCCCCCCCCCCDDDDDDDDDDDDDDDDDDDDDDDDDDDDDD\012" (61)
> INLINE DATA:
> The size of inline data: 121
>
> More detailed information about the file with extended attribute:
>
> debugfs: imap smallfile120.txt
> Inode 16 is part of block group 0
> located at block 65, offset 0x0f00
>
> So we know that it is located in the block 0000065 with offset 0x0f00
> = 0740 octal
>
> debugfs: block_dump 65
> .....
> *
> 7400 a481 0000 7900 0000 5876 1752 6494 1452 ....y...Xv.Rd..R
> 7420 6494 1452 0000 0000 0000 0100 0000 0000 d..R............
> 7440 0000 0010 0100 0000 4141 4141 4141 4141 ........AAAAAAAA
> 7460 4141 4141 4141 4141 4141 4141 4141 4141 AAAAAAAAAAAAAAAA
> 7500 4141 4141 4141 4242 4242 4242 4242 4242 AAAAAABBBBBBBBBB
> 7520 4242 4242 4242 4242 4242 4242 4242 4242 BBBBBBBBBBBBBBBB
> 7540 4242 4242 1b26 bd0d 0000 0000 0000 0000 BBBB.&..........
> 7560 0000 0000 0000 0000 0000 0000 0000 0000 ................
> 7600 1c00 0000 1cdf e204 1cdf e204 48e5 a4c0 ............H...
> 7620 6494 1452 1cdf e204 0000 0000 0000 02ea d..R............
> 7640 0407 2000 0000 0000 3d00 0000 0000 0000 .. .....=.......
> 7660 6461 7461 0000 0000 0000 0000 0000 0000 data............
> 7700 4343 4343 4343 4343 4343 4343 4343 4343 CCCCCCCCCCCCCCCC
> 7720 4343 4343 4343 4343 4343 4343 4343 4444 CCCCCCCCCCCCCCDD
> 7740 4444 4444 4444 4444 4444 4444 4444 4444 DDDDDDDDDDDDDDDD
> 7760 4444 4444 4444 4444 4444 4444 0a00 0000 DDDDDDDDDDDD....
>
> And thats how I got to this place.
>
> thanks,
>
> Felipe Monteiro de Carvalho
>
> On Mon, Sep 2, 2013 at 2:07 PM, Zheng Liu <gnehzuil.liu@...il.com> wrote:
> > Hello,
> >
> > Sorry for my late reply.
> >
> > On Mon, Sep 02, 2013 at 11:40:15AM +0200, Felipe Monteiro de Carvalho wrote:
> >> Hello,
> >>
> >> Ok, I found the extra data over 60 bytes ... it is in an extended
> >> attribute called "data" in the space after the inode. The wiki says it
> >> should be called "system.data" =(
> >>
> >> Also the wiki says here
> >> https://ext4.wiki.kernel.org/index.php/Ext4_Disk_Layout#Extended_Attributes
> >> that "Extended attributes, when >>>not<<<< stored after the inode,
> >> have a header ext4_xattr_ibody_header that is 4 bytes long:"
> >>
> >> Which in my oppinion is false, it should be: "Extended attributes,
> >> when stored after the inode, have a header ext4_xattr_ibody_header
> >> that is 4 bytes long:" without the "not"
> >>
> >> But I still am not sure of one thing: How can I know how many entries
> >> of extended attributes there are? Nothing in the wiki explains this =(
> >
> > You need to traverse the all entries to get this value.
> >
> >>
> >> Otherwise I cannot differentiate between yet another entry and simply
> >> data from an extended attribute...
> >
> > You can use attribute name and name index to differentiate these
> > entries. You can read the comment at the front of fs/ext4/xattr.c and
> > it might help you to understand extended attribute.
> >
> > Regards,
> > - Zheng
>
>
>
> --
> Felipe Monteiro de Carvalho
> --
> 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
--
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
Powered by blists - more mailing lists