From: Mimi Zohar <zohar@linux.vnet.ibm.com>
To: linux-kernel@vger.kernel.org
Cc: Mimi Zohar <zohar@linux.vnet.ibm.com>,
Al Viro <viro@zeniv.linux.org.uk>, Eric Paris <eparis@redhat.com>,
Hugh Dickins <hugh.dickins@tiscali.co.uk>,
James Morris <jmorris@namei.org>,
David Safford <safford@watson.ibm.com>,
"Serge E. Hallyn" <serue@linux.vnet.ibm.com>
Subject: [RFC PATCH 0/2] Fix untangling ima mess, part 2 with counters
Date: Wed, 20 Jan 2010 15:35:39 -0500 [thread overview]
Message-ID: <cover.1264018123.git.zohar@linux.vnet.ibm.com> (raw)
The "Untangling ima mess, part 2 with counters" patch not
only messed up the counters, but also doesn't measure files
which should be measured. The "Untangling ima mess ..."
patchset, applied some of Eric's patches, but not all, leaving
inodes allocated before late_initcall() not allocated/measured.
(8262bb85da ima: initialize ima before inodes can be allocated)
Up to now, measuring files and updating the IMA open/read/write
counters associated with the file were done at the same time
in ima_path_check(). An imbalanced counter was an indication
that the file hadn't been measured. Each case needed to be
inspected, resulting in adding either a new ima_counts_get()
or ima_path_check() call (e.g. nfsd, ecryptfs, openAFS).
This patchset separates incrementing the counters from measuring
the file. However, the underlying assumption is that all regular
files are opened via do_filp_open(). Is this assumption correct or,
by incrementing the file counters separately, have we inadvertently
hidden the fact that a file wasn't measured?
Mimi
next reply other threads:[~2010-01-20 20:36 UTC|newest]
Thread overview: 11+ messages / expand[flat|nested] mbox.gz Atom feed top
2010-01-20 20:35 Mimi Zohar [this message]
2010-01-20 20:35 ` [RFC PATCH 1/2] Fix 1 untangling ima mess, part 2 with counters Mimi Zohar
2010-01-23 23:07 ` Al Viro
2010-01-25 19:24 ` Mimi Zohar
2010-01-25 21:30 ` Al Viro
2010-01-26 13:03 ` Al Viro
2010-01-26 15:16 ` Mimi Zohar
2010-01-26 16:27 ` Al Viro
[not found] ` <1264520125.3789.32.camel@dyn9002018117.watson.ibm.com>
[not found] ` <20100126163143.GJ19799@ZenIV.linux.org.uk>
[not found] ` <1264528747.3062.11.camel@dyn9002018117.watson.ibm.com>
2010-01-26 19:41 ` Open Intents, lookup_instantiate_filp() And All That Shit(tm) Al Viro
2010-01-26 22:01 ` [RFC PATCH 1/2] Fix 1 untangling ima mess, part 2 with counters Mimi Zohar
2010-01-20 20:35 ` [RFC PATCH 2/2] Fix 2 " Mimi Zohar
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=cover.1264018123.git.zohar@linux.vnet.ibm.com \
--to=zohar@linux.vnet.ibm.com \
--cc=eparis@redhat.com \
--cc=hugh.dickins@tiscali.co.uk \
--cc=jmorris@namei.org \
--cc=linux-kernel@vger.kernel.org \
--cc=safford@watson.ibm.com \
--cc=serue@linux.vnet.ibm.com \
--cc=viro@zeniv.linux.org.uk \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox