linux-fsdevel.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Mimi Zohar <zohar@linux.vnet.ibm.com>
To: Jan Kara <jack@suse.cz>
Cc: Christoph Hellwig <hch@lst.de>, Al Viro <viro@zeniv.linux.org.uk>,
	James Morris <jmorris@namei.org>,
	linux-fsdevel@vger.kernel.org,
	linux-ima-devel@lists.sourceforge.net,
	linux-security-module@vger.kernel.org,
	Matthew Garrett <matthew.garrett@nebula.com>,
	Jan Kara <jack@suse.com>, "Theodore Ts'o" <tytso@mit.edu>,
	Andreas Dilger <adilger.kernel@dilger.ca>,
	Jaegeuk Kim <jaegeuk@kernel.org>, Chao Yu <yuchao0@huawei.com>,
	Steven Whitehouse <swhiteho@redhat.com>,
	Bob Peterson <rpeterso@redhat.com>,
	David Woodhouse <dwmw2@infradead.org>,
	Dave Kleikamp <shaggy@kernel.org>,
	Ryusuke Konishi <konishi.ryusuke@lab.ntt.co.jp>,
	Mark Fasheh <mfasheh@versity.com>,
	Joel Becker <jlbec@evilplan.org>,
	Richard Weinberger <richard@nod.at>,
	"Darrick J. Wong" <darrick.wong@oracle.com>,
	Hugh Dickins <hughd@google.com>, Chris Mason <clm@fb.com>
Subject: Re: [PATCH v3 2/4] ima: use fs method to read integrity data
Date: Thu, 13 Jul 2017 15:15:53 -0400	[thread overview]
Message-ID: <1499973353.4220.53.camel@linux.vnet.ibm.com> (raw)
In-Reply-To: <20170713160307.GG5884@quack2.suse.cz>

On Thu, 2017-07-13 at 18:03 +0200, Jan Kara wrote:
> On Thu 13-07-17 09:54:48, Mimi Zohar wrote:
> > diff --git a/fs/ext2/file.c b/fs/ext2/file.c
> > index b21891a6bfca..d57c4259945d 100644
> > --- a/fs/ext2/file.c
> > +++ b/fs/ext2/file.c
> > @@ -219,6 +219,7 @@ const struct file_operations ext2_file_operations = {
> >  	.get_unmapped_area = thp_get_unmapped_area,
> >  	.splice_read	= generic_file_splice_read,
> >  	.splice_write	= iter_file_splice_write,
> > +	.integrity_read	= generic_file_read_iter,
> >  };
> >  
> >  const struct inode_operations ext2_file_inode_operations = {
> > diff --git a/fs/ext4/file.c b/fs/ext4/file.c
> > index 831fd6beebf0..e7b2bd43cdc4 100644
> > --- a/fs/ext4/file.c
> > +++ b/fs/ext4/file.c
> > @@ -753,6 +753,7 @@ const struct file_operations ext4_file_operations = {
> >  	.splice_read	= generic_file_splice_read,
> >  	.splice_write	= iter_file_splice_write,
> >  	.fallocate	= ext4_fallocate,
> > +	.integrity_read	= ext4_file_read_iter,
> >  };
> 
> I think both ext2 and ext4 need a bit more special handling (similarly to
> XFS) due to DAX. E.g. ext4_dax_read_iter() will try to get i_rwsem which is
> wrong for integrity_read handler as far as I understand.

True, thanks.  This will be addressed in the next version.

> > index c2062a108d19..9b49d09ba180 100644
> > --- a/fs/gfs2/file.c
> > +++ b/fs/gfs2/file.c
> > @@ -1124,6 +1124,7 @@ const struct file_operations gfs2_file_fops = {
> >  	.splice_write	= gfs2_file_splice_write,
> >  	.setlease	= simple_nosetlease,
> >  	.fallocate	= gfs2_fallocate,
> > +	.integrity_read	= generic_file_read_iter,
> >  };
> >  
> >  const struct file_operations gfs2_dir_fops = {
> > @@ -1152,6 +1153,7 @@ const struct file_operations gfs2_file_fops_nolock = {
> >  	.splice_write	= gfs2_file_splice_write,
> >  	.setlease	= generic_setlease,
> >  	.fallocate	= gfs2_fallocate,
> > +	.integrity_read	= generic_file_read_iter,
> >  };
> >  
> >  const struct file_operations gfs2_dir_fops_nolock = {
> ...
> > diff --git a/fs/ocfs2/file.c b/fs/ocfs2/file.c
> > index bfeb647459d9..2832a7c92acd 100644
> > --- a/fs/ocfs2/file.c
> > +++ b/fs/ocfs2/file.c
> > @@ -2536,6 +2536,7 @@ const struct file_operations ocfs2_fops = {
> >  	.fallocate	= ocfs2_fallocate,
> >  	.clone_file_range = ocfs2_file_clone_range,
> >  	.dedupe_file_range = ocfs2_file_dedupe_range,
> > +	.integrity_read	= ocfs2_file_read_iter,
> >  };
> >  
> >  const struct file_operations ocfs2_dops = {
> 
> For cluster filesystems like gfs2 or ocfs2 I actually wonder whether IMA
> works as it should - without special cluster locking another node may be
> modifying the file while you read it even when you hold i_rwsem. So don't
> these filesystems need some special treatment?

Both ocf2 and gfs2 can be created as a local filesystem, not only as
part of a cluster.  As part of a clustered node, you're probably
right.  

Mimi

  reply	other threads:[~2017-07-13 19:16 UTC|newest]

Thread overview: 7+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2017-07-13 13:54 [PATCH v3 0/4] define new fs integrity_read method Mimi Zohar
2017-07-13 13:54 ` [PATCH v3 1/4] ima: always measure and audit files in policy Mimi Zohar
2017-07-13 13:54 ` [PATCH v3 2/4] ima: use fs method to read integrity data Mimi Zohar
2017-07-13 16:03   ` Jan Kara
2017-07-13 19:15     ` Mimi Zohar [this message]
2017-07-13 13:54 ` [PATCH v3 3/4] ima: define "dont_failsafe" policy action rule Mimi Zohar
2017-07-13 13:54 ` [PATCH v3 4/4] ima: define "fs_unsafe" builtin policy 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=1499973353.4220.53.camel@linux.vnet.ibm.com \
    --to=zohar@linux.vnet.ibm.com \
    --cc=adilger.kernel@dilger.ca \
    --cc=clm@fb.com \
    --cc=darrick.wong@oracle.com \
    --cc=dwmw2@infradead.org \
    --cc=hch@lst.de \
    --cc=hughd@google.com \
    --cc=jack@suse.com \
    --cc=jack@suse.cz \
    --cc=jaegeuk@kernel.org \
    --cc=jlbec@evilplan.org \
    --cc=jmorris@namei.org \
    --cc=konishi.ryusuke@lab.ntt.co.jp \
    --cc=linux-fsdevel@vger.kernel.org \
    --cc=linux-ima-devel@lists.sourceforge.net \
    --cc=linux-security-module@vger.kernel.org \
    --cc=matthew.garrett@nebula.com \
    --cc=mfasheh@versity.com \
    --cc=richard@nod.at \
    --cc=rpeterso@redhat.com \
    --cc=shaggy@kernel.org \
    --cc=swhiteho@redhat.com \
    --cc=tytso@mit.edu \
    --cc=viro@zeniv.linux.org.uk \
    --cc=yuchao0@huawei.com \
    /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;
as well as URLs for NNTP newsgroup(s).