On Tue, Dec 11, 2012 at 10:12 AM, Kasatkin, Dmitry
[off-list ref] wrote:

Actually S_PRIVATE does not work work for normal filesystems which IMA
might want to ignore.

The reading comprehension here is abysmal.

First you claim that you need the new flag for pseudo-filesystems, and
now that I point out that we have an *old* flag for pseudo-filesystems
you turn around 180 degrees and talk about other filesystems.

And none of that matters for my argument AT ALL.

My argument has not been that we cannot add a new flag.

My argument has been that we already have the logical place for such a
flag, and that adding a totally new field seems so stupid.

Seriously. The i_flags place is where we already do pretty much
*exactly* what you ask for. The fact that it is faster and more
flexible to boot should be a bonus.

Now, there are real reasons to avoid "s_flags", notably the fact that
we're running out of bits there (unlike i_flags), and they are exposed
as generic fields and are generally meant for mount options etc. So I
understand why we might want to avoid that (although the whole
mount-option thing could also be seen as an advantage), but I really
don't see any argument against i_flags, considering that we already
use it for S_IMA and S_PRIVATE, both of which are related to exactly
what you seem to want to do.

The one downside of i_flags may be that any update should own the
inode semaphore. But within the context of a security model, that
should be fine (and normally you'd update it once per lifetime of the
inode).

                  Linus