From: David Howells <dhowells@redhat.com>
To: Trond Myklebust <trond.myklebust@fys.uio.no>
Cc: David Howells <dhowells@redhat.com>,
Stephen Smalley <sds@tycho.nsa.gov>,
Karl MacMillan <kmacmill@redhat.com>,
jmorris@namei.org, chrisw@sous-sol.org, selinux@tycho.nsa.gov,
linux-kernel@vger.kernel.org, aviro@redhat.com
Subject: Re: Security issues with local filesystem caching
Date: Fri, 03 Nov 2006 10:27:01 +0000 [thread overview]
Message-ID: <12984.1162549621@redhat.com> (raw)
In-Reply-To: <1162502667.6071.66.camel@lade.trondhjem.org>
Trond Myklebust <trond.myklebust@fys.uio.no> wrote:
> > Well, both Christoph and Al are of the opinion that I should be using
> > vfs_mkdir() and co rather than bypassing the security and calling inode ops
> > directly.
>
> ...but why are you needing to call vfs_mkdir? I thought the standard
> cachefs backend just uses a pool of files, rather like the original AFS
> cache did. Are you trying to mirror the layout and the permissions of
> the NFS filesystem? That is a lot more work than it is worth...
No.
I have to have a way of mapping a netfs file onto a cache storage object. I do
this by translating the keys the netfs gives me into a path of directory and
file names in the cache.
In NFS's case there are three keys describing a file:
(1) "NFS"
(2) { Server IP, Server port, NFS version }
(3) NFS File Handle
These wind up in the filesystem looking something like:
INDEX INDEX INDEX DATA FILES
========= ========== ================================= ================
cache/@4a/I03nfs/@30/Ji000000000000000--fHg8hi8400
cache/@4a/I03nfs/@30/Ji000000000000000--fHg8hi8400/@75/Es0g000w...DB1ry
cache/@4a/I03nfs/@30/Ji000000000000000--fHg8hi8400/@75/Es0g000w...N22ry
cache/@4a/I03nfs/@30/Ji000000000000000--fHg8hi8400/@75/Es0g000w...FP1ry
See Documentation/filesystems/caching/cachefiles.txt for more information, in
particular the section "Cache Structure".
Anyway, it's not just vfs_mkdir(), there's also vfs_create(), vfs_rename(),
vfs_unlink(), vfs_setxattr(), vfs_getxattr(), and I'm going to need a
vfs_lookup() or something (a pathwalk to next dentry).
Yes, I'd prefer not to have to use these, but that doesn't seem to be an
option.
> > Also I should be setting security labels on the files I create.
>
> To what end? These files shouldn't need to be made visible to userland
> at all.
But they are visible to userland and they have to be visible to userland. They
exist in the filesystem in which the cache resides, and they need to be visible
so that cachefilesd can do the culling work. If you were thinking of using
"deleted" files, remember that I want it to be persistent across reboots, or
even when an NFS inode is flushed from memory to make space and then reloaded
later.
David
next prev parent reply other threads:[~2006-11-03 10:28 UTC|newest]
Thread overview: 56+ messages / expand[flat|nested] mbox.gz Atom feed top
2006-10-25 10:14 Security issues with local filesystem caching David Howells
2006-10-25 16:52 ` Nate Diller
2006-10-25 16:48 ` Jeff V. Merkey
2006-10-25 17:21 ` David Howells
2006-10-25 17:42 ` Jeff V. Merkey
2006-10-25 18:15 ` David Howells
2006-10-25 20:21 ` Josef Sipek
2006-10-25 20:28 ` Josef Sipek
2006-10-26 9:56 ` David Howells
2006-10-27 15:54 ` Josef Sipek
2006-10-25 21:12 ` Stephen Smalley
2006-10-26 10:40 ` David Howells
2006-10-26 12:51 ` Stephen Smalley
2006-10-26 16:04 ` David Howells
2006-10-26 16:34 ` Stephen Smalley
2006-10-26 17:09 ` David Howells
2006-10-26 17:45 ` Stephen Smalley
2006-10-26 22:53 ` David Howells
2006-10-27 14:48 ` Stephen Smalley
2006-10-27 15:42 ` David Howells
2006-10-27 16:10 ` Stephen Smalley
2006-10-27 16:25 ` David Howells
2006-10-27 17:09 ` Stephen Smalley
2006-10-27 17:34 ` David Howells
2006-10-27 14:41 ` David Howells
2006-10-25 23:37 ` Alan Cox
2006-10-26 0:32 ` Al Viro
2006-10-26 10:45 ` David Howells
2006-10-26 10:54 ` Alan Cox
2006-10-26 9:14 ` Jan Dittmer
2006-10-26 10:55 ` David Howells
2006-10-26 11:52 ` Alan Cox
2006-10-31 21:26 ` David Howells
2006-11-01 13:28 ` Stephen Smalley
2006-11-01 15:34 ` David Howells
2006-11-01 15:58 ` Karl MacMillan
2006-11-01 17:45 ` Stephen Smalley
2006-11-02 16:29 ` Karl MacMillan
2006-11-02 18:04 ` Stephen Smalley
2006-11-01 17:30 ` Stephen Smalley
2006-11-02 17:16 ` David Howells
2006-11-02 19:49 ` Trond Myklebust
2006-11-02 20:38 ` David Howells
2006-11-02 21:24 ` Trond Myklebust
2006-11-03 10:27 ` David Howells [this message]
2006-11-03 13:41 ` Trond Myklebust
2006-11-03 15:23 ` David Howells
2006-11-03 17:30 ` Trond Myklebust
2006-11-14 19:22 ` David Howells
2006-11-15 14:05 ` Trond Myklebust
2006-11-15 15:28 ` David Howells
2006-11-15 16:41 ` Trond Myklebust
2006-11-15 18:17 ` David Howells
2006-11-03 15:33 ` David Howells
2006-11-02 20:33 ` Stephen Smalley
2006-11-02 21:05 ` David Howells
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=12984.1162549621@redhat.com \
--to=dhowells@redhat.com \
--cc=aviro@redhat.com \
--cc=chrisw@sous-sol.org \
--cc=jmorris@namei.org \
--cc=kmacmill@redhat.com \
--cc=linux-kernel@vger.kernel.org \
--cc=sds@tycho.nsa.gov \
--cc=selinux@tycho.nsa.gov \
--cc=trond.myklebust@fys.uio.no \
/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