From mboxrd@z Thu Jan 1 00:00:00 1970 From: Eric Paris Subject: Re: [PATCH 1/3] vfs: re-introduce MAY_CHDIR Date: Thu, 6 May 2010 13:42:41 -0400 Message-ID: References: <20100409221614.2681.64052.stgit@paris.rdu.redhat.com> Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: QUOTED-PRINTABLE Cc: selinux@tycho.nsa.gov, linux-fsdevel@vger.kernel.org, jmorris@namei.org, sds@tycho.nsa.gov, casey@schaufler-ca.com, viro@zeniv.linux.org.uk To: Eric Paris Return-path: Received: from mail-vw0-f46.google.com ([209.85.212.46]:38386 "EHLO mail-vw0-f46.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1759237Ab0EFRmm convert rfc822-to-8bit (ORCPT ); Thu, 6 May 2010 13:42:42 -0400 Received: by vws4 with SMTP id 4so64880vws.19 for ; Thu, 06 May 2010 10:42:42 -0700 (PDT) In-Reply-To: <20100409221614.2681.64052.stgit@paris.rdu.redhat.com> Sender: linux-fsdevel-owner@vger.kernel.org List-ID: On Fri, Apr 9, 2010 at 6:16 PM, Eric Paris wrote: > Currently MAY_ACCESS means that filesystems must check the permission= s > right then and not rely on cached results or the results of future > operations on the object. =A0This can be because of a call to sys_acc= ess() or > because of a call to chdir() which needs to check search without rely= ing on > any future operations inside that dir. =A0I plan to use MAY_ACCESS fo= r other > purposes in the security system, so I split the MAY_ACCESS and the > MAY_CHDIR cases. Does anyone, ?Al? have a problem with this patch? If I hear no objections I'm going to ask James to push it through the security tree, but I'd really like to hear any VFS person say they don't mind before doing so. It's obviously safe and doesn't change VFS behaviour at all, but maybe there is some better way to indicate to the LSM that a call came from access(2) rather than read/write. -Eric > > Signed-off-by: Eric Paris > --- > > =A0fs/fuse/dir.c =A0 =A0 =A0| =A0 =A02 +- > =A0fs/nfs/dir.c =A0 =A0 =A0 | =A0 =A02 +- > =A0fs/open.c =A0 =A0 =A0 =A0 =A0| =A0 =A06 +++--- > =A0include/linux/fs.h | =A0 =A01 + > =A04 files changed, 6 insertions(+), 5 deletions(-) > > diff --git a/fs/fuse/dir.c b/fs/fuse/dir.c > index 4787ae6..7c8c55b 100644 > --- a/fs/fuse/dir.c > +++ b/fs/fuse/dir.c > @@ -1016,7 +1016,7 @@ static int fuse_permission(struct inode *inode,= int mask) > =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 exist. =A0So if permissions are r= evoked this won't be > =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 noticed immediately, only after t= he attribute > =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 timeout has expired */ > - =A0 =A0 =A0 } else if (mask & MAY_ACCESS) { > + =A0 =A0 =A0 } else if (mask & (MAY_ACCESS | MAY_CHDIR)) { > =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0err =3D fuse_access(inode, mask); > =A0 =A0 =A0 =A0} else if ((mask & MAY_EXEC) && S_ISREG(inode->i_mode)= ) { > =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0if (!(inode->i_mode & S_IXUGO)) { > diff --git a/fs/nfs/dir.c b/fs/nfs/dir.c > index be46f26..4c7d8fc 100644 > --- a/fs/nfs/dir.c > +++ b/fs/nfs/dir.c > @@ -1927,7 +1927,7 @@ int nfs_permission(struct inode *inode, int mas= k) > =A0 =A0 =A0 =A0if ((mask & (MAY_READ | MAY_WRITE | MAY_EXEC)) =3D=3D = 0) > =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0goto out; > =A0 =A0 =A0 =A0/* Is this sys_access() ? */ > - =A0 =A0 =A0 if (mask & MAY_ACCESS) > + =A0 =A0 =A0 if (mask & (MAY_ACCESS | MAY_CHDIR)) > =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0goto force_lookup; > > =A0 =A0 =A0 =A0switch (inode->i_mode & S_IFMT) { > diff --git a/fs/open.c b/fs/open.c > index b93eac3..d01e116 100644 > --- a/fs/open.c > +++ b/fs/open.c > @@ -534,7 +534,7 @@ SYSCALL_DEFINE1(chdir, const char __user *, filen= ame) > =A0 =A0 =A0 =A0if (error) > =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0goto out; > > - =A0 =A0 =A0 error =3D inode_permission(path.dentry->d_inode, MAY_EX= EC | MAY_ACCESS); > + =A0 =A0 =A0 error =3D inode_permission(path.dentry->d_inode, MAY_EX= EC | MAY_CHDIR); > =A0 =A0 =A0 =A0if (error) > =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0goto dput_and_out; > > @@ -563,7 +563,7 @@ SYSCALL_DEFINE1(fchdir, unsigned int, fd) > =A0 =A0 =A0 =A0if (!S_ISDIR(inode->i_mode)) > =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0goto out_putf; > > - =A0 =A0 =A0 error =3D inode_permission(inode, MAY_EXEC | MAY_ACCESS= ); > + =A0 =A0 =A0 error =3D inode_permission(inode, MAY_EXEC | MAY_CHDIR)= ; > =A0 =A0 =A0 =A0if (!error) > =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0set_fs_pwd(current->fs, &file->f_path)= ; > =A0out_putf: > @@ -581,7 +581,7 @@ SYSCALL_DEFINE1(chroot, const char __user *, file= name) > =A0 =A0 =A0 =A0if (error) > =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0goto out; > > - =A0 =A0 =A0 error =3D inode_permission(path.dentry->d_inode, MAY_EX= EC | MAY_ACCESS); > + =A0 =A0 =A0 error =3D inode_permission(path.dentry->d_inode, MAY_EX= EC | MAY_CHDIR); > =A0 =A0 =A0 =A0if (error) > =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0goto dput_and_out; > > diff --git a/include/linux/fs.h b/include/linux/fs.h > index 14d8597..188d3e4 100644 > --- a/include/linux/fs.h > +++ b/include/linux/fs.h > @@ -53,6 +53,7 @@ struct inodes_stat_t { > =A0#define MAY_APPEND 8 > =A0#define MAY_ACCESS 16 > =A0#define MAY_OPEN 32 > +#define MAY_CHDIR 64 > > =A0/* > =A0* flags in file.f_mode. =A0Note that FMODE_READ and FMODE_WRITE mu= st correspond > > > -- > This message was distributed to subscribers of the selinux mailing li= st. > If you no longer wish to subscribe, send mail to majordomo@tycho.nsa.= gov with > the words "unsubscribe selinux" without quotes as the message. > -- To unsubscribe from this list: send the line "unsubscribe linux-fsdevel= " in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html