Re: SELinux and UBIFS

[Artem Bityutskiy <dedekind1@gmail.com>]

On Thu, 2010-05-27 at 08:25 -0700, Steve Iribarne wrote:
> I've been searching the net and have yet to find any sort of reliable 
> "HOWTO" or "does it work" regarding SELinux, UBIFS and the extended 
> attributes.
> 
> We have need to use this here at Grid-Net and I'm trying to get a handle 
> on if the work is done or is there something else I need to do to 
> complete it.
> 
> I see that there is extended attribute support in the UBIFS, but I've 
> also seen articles (emails/etc..) claiming that the support is not fully 
> there.
> 
> Can someone point me to the right place if there is a right place?

Hi, I added basic xattr support, but never tested xattrs very well. I
did not implement ACL support. And I do not really know SELinux
requirements. So just try it and let us know, better with a patch to the
UBIFS FAQ which you can find here:
http://www.linux-mtd.infradead.org/faq/ubifs.html

and the website sources here:
http://git.infradead.org/mtd-www.git

Here is a comment from fs/ubifs/xattr.c:

/*
 * This file implements UBIFS extended attributes support.
 *
 * Extended attributes are implemented as regular inodes with attached data,
 * which limits extended attribute size to UBIFS block size (4KiB). Names of
 * extended attributes are described by extended attribute entries (xentries),
 * which are almost identical to directory entries, but have different key type.
 *
 * In other words, the situation with extended attributes is very similar to
 * directories. Indeed, any inode (but of course not xattr inodes) may have a
 * number of associated xentries, just like directory inodes have associated
 * directory entries. Extended attribute entries store the name of the extended
 * attribute, the host inode number, and the extended attribute inode number.
 * Similarly, direntries store the name, the parent and the target inode
 * numbers. Thus, most of the common UBIFS mechanisms may be re-used for
 * extended attributes.
 *
 * The number of extended attributes is not limited, but there is Linux
 * limitation on the maximum possible size of the list of all extended
 * attributes associated with an inode (%XATTR_LIST_MAX), so UBIFS makes sure
 * the sum of all extended attribute names of the inode does not exceed that
 * limit.
 *
 * Extended attributes are synchronous, which means they are written to the
 * flash media synchronously and there is no write-back for extended attribute
 * inodes. The extended attribute values are not stored in compressed form on
 * the media.
 *
 * Since extended attributes are represented by regular inodes, they are cached
 * in the VFS inode cache. The xentries are cached in the LNC cache (see
 * tnc.c).
 *
 * ACL support is not implemented.
 */

It seems like the following xattr namespaces are supported:

/*
 * Extended attribute type constants.
 *
 * USER_XATTR: user extended attribute ("user.*")
 * TRUSTED_XATTR: trusted extended attribute ("trusted.*)
 * SECURITY_XATTR: security extended attribute ("security.*")
 */

-- 
Best Regards,
Artem Bityutskiy (Артём Битюцкий)