On Mon, Jul 12, 2010 at 10:36, Stephen Smalley <sds@xxxxxxxxxxxxx> wrote: > On Sat, 2010-07-10 at 22:12 -0700, Casey Schaufler wrote: >> Kyle Moffett wrote: >> > ... >> > Even in local filesystems like ext3 we prefer to turn labels into >> > numbers, store the number with each inode, and then keep the labels >> > indexed in a separate datastructure. >> > >> >> I don't know what system you're talking about, but that notion >> was pretty well dispelled in the late 1980's, after the SystemV/MLS >> and SecureWare examples. > > SELinux did that too before switching to using xattrs for label storage. > Persistent security identifier (PSID) associated with each inode (either > stored directly in the inode in the original kernel patches or > associated through a separate mapping in the LSM-based implementation), > with a mapping from PSID to context stored in a mapping within each > filesystem. Allowed you to keep the labels with the volume but avoided > storing the same label multiple times. > > The xattr based implementation can sometimes share storage but only when > the xattr is stored in the additional block (not when they are stored > inline) and only if all of the xattrs on the file are identical. Hmm, for some reason I was still thinking that we stored an encoded form of the label even in xattrs. Whoops! On the other hand, I guess it should be noted that the "common" case of an SELinux label is the inline storage case, labels are on average no more than ~40 bytes: system_u:object_r:sysadm_homedir_t:s0 In filesystems that are space optimized (like squashfs), we still prefer to pack xattrs, symlinks, and even file permissions as tightly as possible through table lookups of various forms. Heck, the read-only squashfs only stores a single empty-directory inode and references it wherever needed. On the other hand, if you're doing something completely silly with 64k labels then any hope of inline storage went out the window along with any space savings from nifty FS optimizations like de-duplication or tail-packing. Cheers, Kyle Moffett -- To unsubscribe from this list: send the line "unsubscribe linux-fsdevel" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
