Re: [PATCH 06/10] NFSv4: Add label recommended attribute and NFSv4 flags

[Kyle Moffett <kyle@moffetthome.net>]

On Mon, Jul 12, 2010 at 10:36, Stephen Smalley <sds@tycho.nsa.gov> 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