Hi All, I''ve come across the ''gotcha'' in XFS where the inode size defaults to 256 [1] whereas for SELinux the attributes play better when you initialise it at creation to 512. From my reading of the btrfs specs [2] it doesn''t look like you''ll get caught with that as the inodes "will not contain embedded file data or extended attribute data. These things are stored in other item types." Have I read that right? I''ve seen xattr bugs patches etc but nothing that would hit the SE Linux domain. [1] http://www.gentoo.org/proj/en/hardened/selinux/selinux-handbook.xml?part=2&chap=1 [2] http://btrfs.ipv5.de/index.php?title=Btrfs_design#Inodes -- To unsubscribe from this list: send the line "unsubscribe linux-btrfs" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
On Mon, Feb 27, 2012 at 10:18:55PM +0000, Alex wrote:> I''ve come across the ''gotcha'' in XFS where the inode size defaults to 256 [1] > whereas for SELinux the attributes play better when you initialise it at > creation to 512.A btrfs inode structure is 136 bytes in size. xattrs and any inline file data are separate from the inode structure, stored with additional keys in the FS tree (which means that they''re quite likely to appear in the same page, as the inode data, but not guaranteed).> From my reading of the btrfs specs [2] it doesn''t look like you''ll get caught > with that as the inodes "will not contain embedded file data or extended > attribute data. These things are stored in other item types." > > Have I read that right? I''ve seen xattr bugs patches etc but nothing that would > hit the SE Linux domain.It''s not clear from looking at the gentoo doc what the problem actually is with different inode sizes... Without some kind of indication what the issue really is, it''s kind of hard to say how this might affect btrfs. Hugo. -- === Hugo Mills: hugo@... carfax.org.uk | darksatanic.net | lug.org.uk == PGP key: 515C238D from wwwkeys.eu.pgp.net or http://www.carfax.org.uk --- The enemy have elected for Death by Powerpoint. That''s what --- they shall get. -- gdb
On Mon, Feb 27, 2012 at 10:18:55PM +0000, Alex wrote:> From my reading of the btrfs specs [2] it doesn''t look like you''ll get caught > with that as the inodes "will not contain embedded file data or extended > attribute data. These things are stored in other item types." > > Have I read that right? I''ve seen xattr bugs patches etc but nothing that would > hit the SE Linux domain.That''s right. Inode represented as btrfs_inode_item does not contain any xattr fields, they''re stored independently as a btrfs_dir_item of type BTRFS_FT_XATTR . Due to the way the b-tree keys are built, the xattr item key should be stored near the inode item key, that''s for the tree search side. The xattr data are always stored inline in the b-tree leaf. david -- To unsubscribe from this list: send the line "unsubscribe linux-btrfs" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
David Sterba <dave <at> jikos.cz> writes:> > That''s right. Inode represented as btrfs_inode_item does not contain any > xattr fields, they''re stored independently as a btrfs_dir_item of type > BTRFS_FT_XATTR . Due to the way the b-tree keys are built, the xattr > item key should be stored near the inode item key, that''s for the tree > search side. The xattr data are always stored inline in the b-tree leaf. >Thank you David and Hugo, My bad on three counts: 1) My courtesy close seems to have gone missing. Sorry and thank you for replying. 2) I, perhaps, should have pointed to https://wiki.debian.org/SELinux/Setup#Prerequisites _.28kernel_and_filesystems.29 which gives a better explanation. 3) Made it clear that I wasn''t attacking XFS, It''s my fs of (non /boot) choice for some years now; I''m exploring SELinux (after the recent Linux conf au 2012 talk) and know I have used inode size defaults for my xfs init back in the day! Best Al. -- To unsubscribe from this list: send the line "unsubscribe linux-btrfs" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
On Tue, Feb 28, 2012 at 11:30:26AM +0000, Alex wrote:> David Sterba <dave <at> jikos.cz> writes: > > > > > That''s right. Inode represented as btrfs_inode_item does not contain any > > xattr fields, they''re stored independently as a btrfs_dir_item of type > > BTRFS_FT_XATTR . Due to the way the b-tree keys are built, the xattr > > item key should be stored near the inode item key, that''s for the tree > > search side. The xattr data are always stored inline in the b-tree leaf. > > > > > Thank you David and Hugo, > > My bad on three counts: > 1) My courtesy close seems to have gone missing. > Sorry and thank you for replying. > 2) I, perhaps, should have pointed to > https://wiki.debian.org/SELinux/Setup#Prerequisites > _.28kernel_and_filesystems.29 > which gives a better explanation.Aaah, OK, that makes sense now. So: we don''t have the issue over xattr sizes at all. The main issue would then seem to be over atomicity of writing xattrs -- I don''t know what the APIs for this look like, or whether we''ve implemented them, so I can''t comment any further on btrfs''s suitability I''m afraid.> 3) Made it clear that I wasn''t attacking > XFS, It''s my fs of (non /boot) choice > for some years now; I''m exploring SELinux > (after the recent Linux conf au 2012 > talk) and know I have used inode size defaults > for my xfs init back in the day!I certainly didn''t read it as such. Hugo. -- === Hugo Mills: hugo@... carfax.org.uk | darksatanic.net | lug.org.uk == PGP key: 515C238D from wwwkeys.eu.pgp.net or http://www.carfax.org.uk --- In the future, terrorists won''t be carrying their ID cards. --- They''ll be carrying yours. -- Henry Porter, Suspect Nation