[PATCH] FUSE - core
This patch adds FUSE core.
This contains the following files:
o inode.c
- superblock operations (alloc_inode, destroy_inode, read_inode,
clear_inode, put_super, show_options)
- registers FUSE filesystem
o fuse_i.h
- private header file
Requirements
============
The most important difference between orinary filesystems and FUSE is
the fact, that the filesystem data/metadata is provided by a userspace
process run with the privileges of the mount "owner" instead of the
kernel, or some remote entity usually running with elevated
privileges.
The security implication of this is that a non-privileged user must
not be able to use this capability to compromise the system. Obvious
requirements arising from this are:
- mount owner should not be able to get elevated privileges with the
help of the mounted filesystem
- mount owner should not be able to induce undesired behavior in
other users' or the super user's processes
- mount owner should not get illegitimate access to information from
other users' and the super user's processes
These are currently ensured with the following constraints:
1) mount is only allowed to directory or file which the mount owner
can modify without limitation (write access + no sticky bit for
directories)
2) nosuid,nodev mount options are forced
3) any process running with fsuid different from the owner is denied
all access to the filesystem
1) and 2) are ensured by the "fusermount" mount utility which is a
setuid root application doing the actual mount operation.
3) is ensured by a check in the permission() method in kernel
I started thinking about doing 3) in a different way because Christoph
H. made a big deal out of it, saying that FUSE is unacceptable into
mainline in this form.
The suggested use of private namespaces would be OK, but in their
current form have many limitations that make their use impractical (as
discussed in this thread).
Suggested improvements that would address these limitations:
- implement shared subtrees
- allow a process to join an existing namespace (make namespaces
first-class objects)
- implement the namespace creation/joining in a PAM module
With all that in place the check of owner against current->fsuid may
be removed from the FUSE kernel module, without compromising the
security requirements.
Suid programs still interesting questions, since they get access even
to the private namespace causing some information leak (exact
order/timing of filesystem operations performed), giving some
ptrace-like capabilities to unprivileged users. BTW this problem is
not strictly limited to the namespace approach, since suid programs
setting fsuid and accessing users' files will succeed with the current
approach too.
Signed-off-by: Miklos Szeredi <miklos@szeredi.hu>
Signed-off-by: Andrew Morton <akpm@osdl.org>
Signed-off-by: Linus Torvalds <torvalds@osdl.org>
2005-09-09 20:10:26 +00:00
|
|
|
/*
|
|
|
|
FUSE: Filesystem in Userspace
|
2008-11-26 11:03:54 +00:00
|
|
|
Copyright (C) 2001-2008 Miklos Szeredi <miklos@szeredi.hu>
|
[PATCH] FUSE - core
This patch adds FUSE core.
This contains the following files:
o inode.c
- superblock operations (alloc_inode, destroy_inode, read_inode,
clear_inode, put_super, show_options)
- registers FUSE filesystem
o fuse_i.h
- private header file
Requirements
============
The most important difference between orinary filesystems and FUSE is
the fact, that the filesystem data/metadata is provided by a userspace
process run with the privileges of the mount "owner" instead of the
kernel, or some remote entity usually running with elevated
privileges.
The security implication of this is that a non-privileged user must
not be able to use this capability to compromise the system. Obvious
requirements arising from this are:
- mount owner should not be able to get elevated privileges with the
help of the mounted filesystem
- mount owner should not be able to induce undesired behavior in
other users' or the super user's processes
- mount owner should not get illegitimate access to information from
other users' and the super user's processes
These are currently ensured with the following constraints:
1) mount is only allowed to directory or file which the mount owner
can modify without limitation (write access + no sticky bit for
directories)
2) nosuid,nodev mount options are forced
3) any process running with fsuid different from the owner is denied
all access to the filesystem
1) and 2) are ensured by the "fusermount" mount utility which is a
setuid root application doing the actual mount operation.
3) is ensured by a check in the permission() method in kernel
I started thinking about doing 3) in a different way because Christoph
H. made a big deal out of it, saying that FUSE is unacceptable into
mainline in this form.
The suggested use of private namespaces would be OK, but in their
current form have many limitations that make their use impractical (as
discussed in this thread).
Suggested improvements that would address these limitations:
- implement shared subtrees
- allow a process to join an existing namespace (make namespaces
first-class objects)
- implement the namespace creation/joining in a PAM module
With all that in place the check of owner against current->fsuid may
be removed from the FUSE kernel module, without compromising the
security requirements.
Suid programs still interesting questions, since they get access even
to the private namespace causing some information leak (exact
order/timing of filesystem operations performed), giving some
ptrace-like capabilities to unprivileged users. BTW this problem is
not strictly limited to the namespace approach, since suid programs
setting fsuid and accessing users' files will succeed with the current
approach too.
Signed-off-by: Miklos Szeredi <miklos@szeredi.hu>
Signed-off-by: Andrew Morton <akpm@osdl.org>
Signed-off-by: Linus Torvalds <torvalds@osdl.org>
2005-09-09 20:10:26 +00:00
|
|
|
|
|
|
|
This program can be distributed under the terms of the GNU GPL.
|
|
|
|
See the file COPYING.
|
|
|
|
*/
|
|
|
|
|
2008-10-16 14:08:57 +00:00
|
|
|
#ifndef _FS_FUSE_I_H
|
|
|
|
#define _FS_FUSE_I_H
|
|
|
|
|
[PATCH] FUSE - core
This patch adds FUSE core.
This contains the following files:
o inode.c
- superblock operations (alloc_inode, destroy_inode, read_inode,
clear_inode, put_super, show_options)
- registers FUSE filesystem
o fuse_i.h
- private header file
Requirements
============
The most important difference between orinary filesystems and FUSE is
the fact, that the filesystem data/metadata is provided by a userspace
process run with the privileges of the mount "owner" instead of the
kernel, or some remote entity usually running with elevated
privileges.
The security implication of this is that a non-privileged user must
not be able to use this capability to compromise the system. Obvious
requirements arising from this are:
- mount owner should not be able to get elevated privileges with the
help of the mounted filesystem
- mount owner should not be able to induce undesired behavior in
other users' or the super user's processes
- mount owner should not get illegitimate access to information from
other users' and the super user's processes
These are currently ensured with the following constraints:
1) mount is only allowed to directory or file which the mount owner
can modify without limitation (write access + no sticky bit for
directories)
2) nosuid,nodev mount options are forced
3) any process running with fsuid different from the owner is denied
all access to the filesystem
1) and 2) are ensured by the "fusermount" mount utility which is a
setuid root application doing the actual mount operation.
3) is ensured by a check in the permission() method in kernel
I started thinking about doing 3) in a different way because Christoph
H. made a big deal out of it, saying that FUSE is unacceptable into
mainline in this form.
The suggested use of private namespaces would be OK, but in their
current form have many limitations that make their use impractical (as
discussed in this thread).
Suggested improvements that would address these limitations:
- implement shared subtrees
- allow a process to join an existing namespace (make namespaces
first-class objects)
- implement the namespace creation/joining in a PAM module
With all that in place the check of owner against current->fsuid may
be removed from the FUSE kernel module, without compromising the
security requirements.
Suid programs still interesting questions, since they get access even
to the private namespace causing some information leak (exact
order/timing of filesystem operations performed), giving some
ptrace-like capabilities to unprivileged users. BTW this problem is
not strictly limited to the namespace approach, since suid programs
setting fsuid and accessing users' files will succeed with the current
approach too.
Signed-off-by: Miklos Szeredi <miklos@szeredi.hu>
Signed-off-by: Andrew Morton <akpm@osdl.org>
Signed-off-by: Linus Torvalds <torvalds@osdl.org>
2005-09-09 20:10:26 +00:00
|
|
|
#include <linux/fuse.h>
|
|
|
|
#include <linux/fs.h>
|
2006-06-25 12:48:50 +00:00
|
|
|
#include <linux/mount.h>
|
[PATCH] FUSE - core
This patch adds FUSE core.
This contains the following files:
o inode.c
- superblock operations (alloc_inode, destroy_inode, read_inode,
clear_inode, put_super, show_options)
- registers FUSE filesystem
o fuse_i.h
- private header file
Requirements
============
The most important difference between orinary filesystems and FUSE is
the fact, that the filesystem data/metadata is provided by a userspace
process run with the privileges of the mount "owner" instead of the
kernel, or some remote entity usually running with elevated
privileges.
The security implication of this is that a non-privileged user must
not be able to use this capability to compromise the system. Obvious
requirements arising from this are:
- mount owner should not be able to get elevated privileges with the
help of the mounted filesystem
- mount owner should not be able to induce undesired behavior in
other users' or the super user's processes
- mount owner should not get illegitimate access to information from
other users' and the super user's processes
These are currently ensured with the following constraints:
1) mount is only allowed to directory or file which the mount owner
can modify without limitation (write access + no sticky bit for
directories)
2) nosuid,nodev mount options are forced
3) any process running with fsuid different from the owner is denied
all access to the filesystem
1) and 2) are ensured by the "fusermount" mount utility which is a
setuid root application doing the actual mount operation.
3) is ensured by a check in the permission() method in kernel
I started thinking about doing 3) in a different way because Christoph
H. made a big deal out of it, saying that FUSE is unacceptable into
mainline in this form.
The suggested use of private namespaces would be OK, but in their
current form have many limitations that make their use impractical (as
discussed in this thread).
Suggested improvements that would address these limitations:
- implement shared subtrees
- allow a process to join an existing namespace (make namespaces
first-class objects)
- implement the namespace creation/joining in a PAM module
With all that in place the check of owner against current->fsuid may
be removed from the FUSE kernel module, without compromising the
security requirements.
Suid programs still interesting questions, since they get access even
to the private namespace causing some information leak (exact
order/timing of filesystem operations performed), giving some
ptrace-like capabilities to unprivileged users. BTW this problem is
not strictly limited to the namespace approach, since suid programs
setting fsuid and accessing users' files will succeed with the current
approach too.
Signed-off-by: Miklos Szeredi <miklos@szeredi.hu>
Signed-off-by: Andrew Morton <akpm@osdl.org>
Signed-off-by: Linus Torvalds <torvalds@osdl.org>
2005-09-09 20:10:26 +00:00
|
|
|
#include <linux/wait.h>
|
|
|
|
#include <linux/list.h>
|
|
|
|
#include <linux/spinlock.h>
|
|
|
|
#include <linux/mm.h>
|
|
|
|
#include <linux/backing-dev.h>
|
2006-06-25 12:48:51 +00:00
|
|
|
#include <linux/mutex.h>
|
fuse: support writable mmap
Quoting Linus (3 years ago, FUSE inclusion discussions):
"User-space filesystems are hard to get right. I'd claim that they
are almost impossible, unless you limit them somehow (shared
writable mappings are the nastiest part - if you don't have those,
you can reasonably limit your problems by limiting the number of
dirty pages you accept through normal "write()" calls)."
Instead of attempting the impossible, I've just waited for the dirty page
accounting infrastructure to materialize (thanks to Peter Zijlstra and
others). This nicely solved the biggest problem: limiting the number of pages
used for write caching.
Some small details remained, however, which this largish patch attempts to
address. It provides a page writeback implementation for fuse, which is
completely safe against VM related deadlocks. Performance may not be very
good for certain usage patterns, but generally it should be acceptable.
It has been tested extensively with fsx-linux and bash-shared-mapping.
Fuse page writeback design
--------------------------
fuse_writepage() allocates a new temporary page with GFP_NOFS|__GFP_HIGHMEM.
It copies the contents of the original page, and queues a WRITE request to the
userspace filesystem using this temp page.
The writeback is finished instantly from the MM's point of view: the page is
removed from the radix trees, and the PageDirty and PageWriteback flags are
cleared.
For the duration of the actual write, the NR_WRITEBACK_TEMP counter is
incremented. The per-bdi writeback count is not decremented until the actual
write completes.
On dirtying the page, fuse waits for a previous write to finish before
proceeding. This makes sure, there can only be one temporary page used at a
time for one cached page.
This approach is wasteful in both memory and CPU bandwidth, so why is this
complication needed?
The basic problem is that there can be no guarantee about the time in which
the userspace filesystem will complete a write. It may be buggy or even
malicious, and fail to complete WRITE requests. We don't want unrelated parts
of the system to grind to a halt in such cases.
Also a filesystem may need additional resources (particularly memory) to
complete a WRITE request. There's a great danger of a deadlock if that
allocation may wait for the writepage to finish.
Currently there are several cases where the kernel can block on page
writeback:
- allocation order is larger than PAGE_ALLOC_COSTLY_ORDER
- page migration
- throttle_vm_writeout (through NR_WRITEBACK)
- sync(2)
Of course in some cases (fsync, msync) we explicitly want to allow blocking.
So for these cases new code has to be added to fuse, since the VM is not
tracking writeback pages for us any more.
As an extra safetly measure, the maximum dirty ratio allocated to a single
fuse filesystem is set to 1% by default. This way one (or several) buggy or
malicious fuse filesystems cannot slow down the rest of the system by hogging
dirty memory.
With appropriate privileges, this limit can be raised through
'/sys/class/bdi/<bdi>/max_ratio'.
Signed-off-by: Miklos Szeredi <mszeredi@suse.cz>
Cc: Peter Zijlstra <a.p.zijlstra@chello.nl>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
2008-04-30 07:54:41 +00:00
|
|
|
#include <linux/rwsem.h>
|
2008-11-26 11:03:55 +00:00
|
|
|
#include <linux/rbtree.h>
|
|
|
|
#include <linux/poll.h>
|
2011-02-25 13:44:58 +00:00
|
|
|
#include <linux/workqueue.h>
|
[PATCH] FUSE - core
This patch adds FUSE core.
This contains the following files:
o inode.c
- superblock operations (alloc_inode, destroy_inode, read_inode,
clear_inode, put_super, show_options)
- registers FUSE filesystem
o fuse_i.h
- private header file
Requirements
============
The most important difference between orinary filesystems and FUSE is
the fact, that the filesystem data/metadata is provided by a userspace
process run with the privileges of the mount "owner" instead of the
kernel, or some remote entity usually running with elevated
privileges.
The security implication of this is that a non-privileged user must
not be able to use this capability to compromise the system. Obvious
requirements arising from this are:
- mount owner should not be able to get elevated privileges with the
help of the mounted filesystem
- mount owner should not be able to induce undesired behavior in
other users' or the super user's processes
- mount owner should not get illegitimate access to information from
other users' and the super user's processes
These are currently ensured with the following constraints:
1) mount is only allowed to directory or file which the mount owner
can modify without limitation (write access + no sticky bit for
directories)
2) nosuid,nodev mount options are forced
3) any process running with fsuid different from the owner is denied
all access to the filesystem
1) and 2) are ensured by the "fusermount" mount utility which is a
setuid root application doing the actual mount operation.
3) is ensured by a check in the permission() method in kernel
I started thinking about doing 3) in a different way because Christoph
H. made a big deal out of it, saying that FUSE is unacceptable into
mainline in this form.
The suggested use of private namespaces would be OK, but in their
current form have many limitations that make their use impractical (as
discussed in this thread).
Suggested improvements that would address these limitations:
- implement shared subtrees
- allow a process to join an existing namespace (make namespaces
first-class objects)
- implement the namespace creation/joining in a PAM module
With all that in place the check of owner against current->fsuid may
be removed from the FUSE kernel module, without compromising the
security requirements.
Suid programs still interesting questions, since they get access even
to the private namespace causing some information leak (exact
order/timing of filesystem operations performed), giving some
ptrace-like capabilities to unprivileged users. BTW this problem is
not strictly limited to the namespace approach, since suid programs
setting fsuid and accessing users' files will succeed with the current
approach too.
Signed-off-by: Miklos Szeredi <miklos@szeredi.hu>
Signed-off-by: Andrew Morton <akpm@osdl.org>
Signed-off-by: Linus Torvalds <torvalds@osdl.org>
2005-09-09 20:10:26 +00:00
|
|
|
|
2005-09-09 20:10:27 +00:00
|
|
|
/** Max number of pages that can be used in a single read request */
|
|
|
|
#define FUSE_MAX_PAGES_PER_REQ 32
|
|
|
|
|
fuse: support writable mmap
Quoting Linus (3 years ago, FUSE inclusion discussions):
"User-space filesystems are hard to get right. I'd claim that they
are almost impossible, unless you limit them somehow (shared
writable mappings are the nastiest part - if you don't have those,
you can reasonably limit your problems by limiting the number of
dirty pages you accept through normal "write()" calls)."
Instead of attempting the impossible, I've just waited for the dirty page
accounting infrastructure to materialize (thanks to Peter Zijlstra and
others). This nicely solved the biggest problem: limiting the number of pages
used for write caching.
Some small details remained, however, which this largish patch attempts to
address. It provides a page writeback implementation for fuse, which is
completely safe against VM related deadlocks. Performance may not be very
good for certain usage patterns, but generally it should be acceptable.
It has been tested extensively with fsx-linux and bash-shared-mapping.
Fuse page writeback design
--------------------------
fuse_writepage() allocates a new temporary page with GFP_NOFS|__GFP_HIGHMEM.
It copies the contents of the original page, and queues a WRITE request to the
userspace filesystem using this temp page.
The writeback is finished instantly from the MM's point of view: the page is
removed from the radix trees, and the PageDirty and PageWriteback flags are
cleared.
For the duration of the actual write, the NR_WRITEBACK_TEMP counter is
incremented. The per-bdi writeback count is not decremented until the actual
write completes.
On dirtying the page, fuse waits for a previous write to finish before
proceeding. This makes sure, there can only be one temporary page used at a
time for one cached page.
This approach is wasteful in both memory and CPU bandwidth, so why is this
complication needed?
The basic problem is that there can be no guarantee about the time in which
the userspace filesystem will complete a write. It may be buggy or even
malicious, and fail to complete WRITE requests. We don't want unrelated parts
of the system to grind to a halt in such cases.
Also a filesystem may need additional resources (particularly memory) to
complete a WRITE request. There's a great danger of a deadlock if that
allocation may wait for the writepage to finish.
Currently there are several cases where the kernel can block on page
writeback:
- allocation order is larger than PAGE_ALLOC_COSTLY_ORDER
- page migration
- throttle_vm_writeout (through NR_WRITEBACK)
- sync(2)
Of course in some cases (fsync, msync) we explicitly want to allow blocking.
So for these cases new code has to be added to fuse, since the VM is not
tracking writeback pages for us any more.
As an extra safetly measure, the maximum dirty ratio allocated to a single
fuse filesystem is set to 1% by default. This way one (or several) buggy or
malicious fuse filesystems cannot slow down the rest of the system by hogging
dirty memory.
With appropriate privileges, this limit can be raised through
'/sys/class/bdi/<bdi>/max_ratio'.
Signed-off-by: Miklos Szeredi <mszeredi@suse.cz>
Cc: Peter Zijlstra <a.p.zijlstra@chello.nl>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
2008-04-30 07:54:41 +00:00
|
|
|
/** Bias for fi->writectr, meaning new writepages must not be sent */
|
|
|
|
#define FUSE_NOWRITE INT_MIN
|
|
|
|
|
2006-01-06 08:19:40 +00:00
|
|
|
/** It could be as large as PATH_MAX, but would that have any uses? */
|
|
|
|
#define FUSE_NAME_MAX 1024
|
|
|
|
|
2006-06-25 12:48:51 +00:00
|
|
|
/** Number of dentries for each connection in the control filesystem */
|
2009-08-26 17:18:24 +00:00
|
|
|
#define FUSE_CTL_NUM_DENTRIES 5
|
2006-06-25 12:48:51 +00:00
|
|
|
|
2005-09-09 20:10:31 +00:00
|
|
|
/** If the FUSE_DEFAULT_PERMISSIONS flag is given, the filesystem
|
|
|
|
module will check permissions based on the file mode. Otherwise no
|
|
|
|
permission checking is done in the kernel */
|
|
|
|
#define FUSE_DEFAULT_PERMISSIONS (1 << 0)
|
|
|
|
|
|
|
|
/** If the FUSE_ALLOW_OTHER flag is given, then not only the user
|
|
|
|
doing the mount will be allowed to access the filesystem */
|
|
|
|
#define FUSE_ALLOW_OTHER (1 << 1)
|
|
|
|
|
2012-10-26 15:48:07 +00:00
|
|
|
/** Number of page pointers embedded in fuse_req */
|
|
|
|
#define FUSE_REQ_INLINE_PAGES 1
|
|
|
|
|
2006-06-25 12:48:51 +00:00
|
|
|
/** List of active connections */
|
|
|
|
extern struct list_head fuse_conn_list;
|
|
|
|
|
|
|
|
/** Global mutex protecting fuse_conn_list and the control filesystem */
|
|
|
|
extern struct mutex fuse_mutex;
|
2005-09-09 20:10:35 +00:00
|
|
|
|
2009-08-26 17:18:24 +00:00
|
|
|
/** Module parameters */
|
|
|
|
extern unsigned max_user_bgreq;
|
|
|
|
extern unsigned max_user_congthresh;
|
|
|
|
|
2010-12-07 19:16:56 +00:00
|
|
|
/* One forget request */
|
|
|
|
struct fuse_forget_link {
|
2010-12-07 19:16:56 +00:00
|
|
|
struct fuse_forget_one forget_one;
|
2010-12-07 19:16:56 +00:00
|
|
|
struct fuse_forget_link *next;
|
|
|
|
};
|
|
|
|
|
[PATCH] FUSE - core
This patch adds FUSE core.
This contains the following files:
o inode.c
- superblock operations (alloc_inode, destroy_inode, read_inode,
clear_inode, put_super, show_options)
- registers FUSE filesystem
o fuse_i.h
- private header file
Requirements
============
The most important difference between orinary filesystems and FUSE is
the fact, that the filesystem data/metadata is provided by a userspace
process run with the privileges of the mount "owner" instead of the
kernel, or some remote entity usually running with elevated
privileges.
The security implication of this is that a non-privileged user must
not be able to use this capability to compromise the system. Obvious
requirements arising from this are:
- mount owner should not be able to get elevated privileges with the
help of the mounted filesystem
- mount owner should not be able to induce undesired behavior in
other users' or the super user's processes
- mount owner should not get illegitimate access to information from
other users' and the super user's processes
These are currently ensured with the following constraints:
1) mount is only allowed to directory or file which the mount owner
can modify without limitation (write access + no sticky bit for
directories)
2) nosuid,nodev mount options are forced
3) any process running with fsuid different from the owner is denied
all access to the filesystem
1) and 2) are ensured by the "fusermount" mount utility which is a
setuid root application doing the actual mount operation.
3) is ensured by a check in the permission() method in kernel
I started thinking about doing 3) in a different way because Christoph
H. made a big deal out of it, saying that FUSE is unacceptable into
mainline in this form.
The suggested use of private namespaces would be OK, but in their
current form have many limitations that make their use impractical (as
discussed in this thread).
Suggested improvements that would address these limitations:
- implement shared subtrees
- allow a process to join an existing namespace (make namespaces
first-class objects)
- implement the namespace creation/joining in a PAM module
With all that in place the check of owner against current->fsuid may
be removed from the FUSE kernel module, without compromising the
security requirements.
Suid programs still interesting questions, since they get access even
to the private namespace causing some information leak (exact
order/timing of filesystem operations performed), giving some
ptrace-like capabilities to unprivileged users. BTW this problem is
not strictly limited to the namespace approach, since suid programs
setting fsuid and accessing users' files will succeed with the current
approach too.
Signed-off-by: Miklos Szeredi <miklos@szeredi.hu>
Signed-off-by: Andrew Morton <akpm@osdl.org>
Signed-off-by: Linus Torvalds <torvalds@osdl.org>
2005-09-09 20:10:26 +00:00
|
|
|
/** FUSE inode */
|
|
|
|
struct fuse_inode {
|
|
|
|
/** Inode data */
|
|
|
|
struct inode inode;
|
|
|
|
|
|
|
|
/** Unique ID, which identifies the inode between userspace
|
|
|
|
* and kernel */
|
|
|
|
u64 nodeid;
|
|
|
|
|
2005-09-09 20:10:29 +00:00
|
|
|
/** Number of lookups on this inode */
|
|
|
|
u64 nlookup;
|
|
|
|
|
2005-09-09 20:10:28 +00:00
|
|
|
/** The request used for sending the FORGET message */
|
2010-12-07 19:16:56 +00:00
|
|
|
struct fuse_forget_link *forget;
|
2005-09-09 20:10:28 +00:00
|
|
|
|
[PATCH] FUSE - core
This patch adds FUSE core.
This contains the following files:
o inode.c
- superblock operations (alloc_inode, destroy_inode, read_inode,
clear_inode, put_super, show_options)
- registers FUSE filesystem
o fuse_i.h
- private header file
Requirements
============
The most important difference between orinary filesystems and FUSE is
the fact, that the filesystem data/metadata is provided by a userspace
process run with the privileges of the mount "owner" instead of the
kernel, or some remote entity usually running with elevated
privileges.
The security implication of this is that a non-privileged user must
not be able to use this capability to compromise the system. Obvious
requirements arising from this are:
- mount owner should not be able to get elevated privileges with the
help of the mounted filesystem
- mount owner should not be able to induce undesired behavior in
other users' or the super user's processes
- mount owner should not get illegitimate access to information from
other users' and the super user's processes
These are currently ensured with the following constraints:
1) mount is only allowed to directory or file which the mount owner
can modify without limitation (write access + no sticky bit for
directories)
2) nosuid,nodev mount options are forced
3) any process running with fsuid different from the owner is denied
all access to the filesystem
1) and 2) are ensured by the "fusermount" mount utility which is a
setuid root application doing the actual mount operation.
3) is ensured by a check in the permission() method in kernel
I started thinking about doing 3) in a different way because Christoph
H. made a big deal out of it, saying that FUSE is unacceptable into
mainline in this form.
The suggested use of private namespaces would be OK, but in their
current form have many limitations that make their use impractical (as
discussed in this thread).
Suggested improvements that would address these limitations:
- implement shared subtrees
- allow a process to join an existing namespace (make namespaces
first-class objects)
- implement the namespace creation/joining in a PAM module
With all that in place the check of owner against current->fsuid may
be removed from the FUSE kernel module, without compromising the
security requirements.
Suid programs still interesting questions, since they get access even
to the private namespace causing some information leak (exact
order/timing of filesystem operations performed), giving some
ptrace-like capabilities to unprivileged users. BTW this problem is
not strictly limited to the namespace approach, since suid programs
setting fsuid and accessing users' files will succeed with the current
approach too.
Signed-off-by: Miklos Szeredi <miklos@szeredi.hu>
Signed-off-by: Andrew Morton <akpm@osdl.org>
Signed-off-by: Linus Torvalds <torvalds@osdl.org>
2005-09-09 20:10:26 +00:00
|
|
|
/** Time in jiffies until the file attributes are valid */
|
2006-07-30 10:04:10 +00:00
|
|
|
u64 i_time;
|
2007-10-17 06:31:03 +00:00
|
|
|
|
|
|
|
/** The sticky bit in inode->i_mode may have been removed, so
|
|
|
|
preserve the original mode */
|
2011-07-26 07:17:33 +00:00
|
|
|
umode_t orig_i_mode;
|
fuse: fix race between getattr and write
Getattr and lookup operations can be running in parallel to attribute changing
operations, such as write and setattr.
This means, that if for example getattr was slower than a write, the cached
size attribute could be set to a stale value.
To prevent this race, introduce a per-filesystem attribute version counter.
This counter is incremented whenever cached attributes are modified, and the
incremented value stored in the inode.
Before storing new attributes in the cache, getattr and lookup check, using
the version number, whether the attributes have been modified during the
request's lifetime. If so, the returned attributes are not cached, because
they might be stale.
Thanks to Jakub Bogusz for the bug report and test program.
[akpm@linux-foundation.org: coding-style fixes]
Signed-off-by: Miklos Szeredi <mszeredi@suse.cz>
Cc: Jakub Bogusz <jakub.bogusz@gemius.pl>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
2007-10-18 10:06:58 +00:00
|
|
|
|
2012-05-10 15:49:38 +00:00
|
|
|
/** 64 bit inode number */
|
|
|
|
u64 orig_ino;
|
|
|
|
|
fuse: fix race between getattr and write
Getattr and lookup operations can be running in parallel to attribute changing
operations, such as write and setattr.
This means, that if for example getattr was slower than a write, the cached
size attribute could be set to a stale value.
To prevent this race, introduce a per-filesystem attribute version counter.
This counter is incremented whenever cached attributes are modified, and the
incremented value stored in the inode.
Before storing new attributes in the cache, getattr and lookup check, using
the version number, whether the attributes have been modified during the
request's lifetime. If so, the returned attributes are not cached, because
they might be stale.
Thanks to Jakub Bogusz for the bug report and test program.
[akpm@linux-foundation.org: coding-style fixes]
Signed-off-by: Miklos Szeredi <mszeredi@suse.cz>
Cc: Jakub Bogusz <jakub.bogusz@gemius.pl>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
2007-10-18 10:06:58 +00:00
|
|
|
/** Version of last attribute change */
|
|
|
|
u64 attr_version;
|
2007-10-18 10:07:03 +00:00
|
|
|
|
|
|
|
/** Files usable in writepage. Protected by fc->lock */
|
|
|
|
struct list_head write_files;
|
fuse: support writable mmap
Quoting Linus (3 years ago, FUSE inclusion discussions):
"User-space filesystems are hard to get right. I'd claim that they
are almost impossible, unless you limit them somehow (shared
writable mappings are the nastiest part - if you don't have those,
you can reasonably limit your problems by limiting the number of
dirty pages you accept through normal "write()" calls)."
Instead of attempting the impossible, I've just waited for the dirty page
accounting infrastructure to materialize (thanks to Peter Zijlstra and
others). This nicely solved the biggest problem: limiting the number of pages
used for write caching.
Some small details remained, however, which this largish patch attempts to
address. It provides a page writeback implementation for fuse, which is
completely safe against VM related deadlocks. Performance may not be very
good for certain usage patterns, but generally it should be acceptable.
It has been tested extensively with fsx-linux and bash-shared-mapping.
Fuse page writeback design
--------------------------
fuse_writepage() allocates a new temporary page with GFP_NOFS|__GFP_HIGHMEM.
It copies the contents of the original page, and queues a WRITE request to the
userspace filesystem using this temp page.
The writeback is finished instantly from the MM's point of view: the page is
removed from the radix trees, and the PageDirty and PageWriteback flags are
cleared.
For the duration of the actual write, the NR_WRITEBACK_TEMP counter is
incremented. The per-bdi writeback count is not decremented until the actual
write completes.
On dirtying the page, fuse waits for a previous write to finish before
proceeding. This makes sure, there can only be one temporary page used at a
time for one cached page.
This approach is wasteful in both memory and CPU bandwidth, so why is this
complication needed?
The basic problem is that there can be no guarantee about the time in which
the userspace filesystem will complete a write. It may be buggy or even
malicious, and fail to complete WRITE requests. We don't want unrelated parts
of the system to grind to a halt in such cases.
Also a filesystem may need additional resources (particularly memory) to
complete a WRITE request. There's a great danger of a deadlock if that
allocation may wait for the writepage to finish.
Currently there are several cases where the kernel can block on page
writeback:
- allocation order is larger than PAGE_ALLOC_COSTLY_ORDER
- page migration
- throttle_vm_writeout (through NR_WRITEBACK)
- sync(2)
Of course in some cases (fsync, msync) we explicitly want to allow blocking.
So for these cases new code has to be added to fuse, since the VM is not
tracking writeback pages for us any more.
As an extra safetly measure, the maximum dirty ratio allocated to a single
fuse filesystem is set to 1% by default. This way one (or several) buggy or
malicious fuse filesystems cannot slow down the rest of the system by hogging
dirty memory.
With appropriate privileges, this limit can be raised through
'/sys/class/bdi/<bdi>/max_ratio'.
Signed-off-by: Miklos Szeredi <mszeredi@suse.cz>
Cc: Peter Zijlstra <a.p.zijlstra@chello.nl>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
2008-04-30 07:54:41 +00:00
|
|
|
|
|
|
|
/** Writepages pending on truncate or fsync */
|
|
|
|
struct list_head queued_writes;
|
|
|
|
|
|
|
|
/** Number of sent writes, a negative bias (FUSE_NOWRITE)
|
|
|
|
* means more writes are blocked */
|
|
|
|
int writectr;
|
|
|
|
|
|
|
|
/** Waitq for writepage completion */
|
|
|
|
wait_queue_head_t page_waitq;
|
|
|
|
|
|
|
|
/** List of writepage requestst (pending or sent) */
|
|
|
|
struct list_head writepages;
|
2013-01-15 03:23:28 +00:00
|
|
|
|
|
|
|
/** Miscellaneous bits describing inode state */
|
|
|
|
unsigned long state;
|
|
|
|
};
|
|
|
|
|
|
|
|
/** FUSE inode state bits */
|
|
|
|
enum {
|
|
|
|
/** Advise readdirplus */
|
|
|
|
FUSE_I_ADVISE_RDPLUS,
|
2013-10-01 14:41:22 +00:00
|
|
|
/** Initialized with readdirplus */
|
|
|
|
FUSE_I_INIT_RDPLUS,
|
fuse: hotfix truncate_pagecache() issue
The way how fuse calls truncate_pagecache() from fuse_change_attributes()
is completely wrong. Because, w/o i_mutex held, we never sure whether
'oldsize' and 'attr->size' are valid by the time of execution of
truncate_pagecache(inode, oldsize, attr->size). In fact, as soon as we
released fc->lock in the middle of fuse_change_attributes(), we completely
loose control of actions which may happen with given inode until we reach
truncate_pagecache. The list of potentially dangerous actions includes
mmap-ed reads and writes, ftruncate(2) and write(2) extending file size.
The typical outcome of doing truncate_pagecache() with outdated arguments
is data corruption from user point of view. This is (in some sense)
acceptable in cases when the issue is triggered by a change of the file on
the server (i.e. externally wrt fuse operation), but it is absolutely
intolerable in scenarios when a single fuse client modifies a file without
any external intervention. A real life case I discovered by fsx-linux
looked like this:
1. Shrinking ftruncate(2) comes to fuse_do_setattr(). The latter sends
FUSE_SETATTR to the server synchronously, but before getting fc->lock ...
2. fuse_dentry_revalidate() is asynchronously called. It sends FUSE_LOOKUP
to the server synchronously, then calls fuse_change_attributes(). The
latter updates i_size, releases fc->lock, but before comparing oldsize vs
attr->size..
3. fuse_do_setattr() from the first step proceeds by acquiring fc->lock and
updating attributes and i_size, but now oldsize is equal to
outarg.attr.size because i_size has just been updated (step 2). Hence,
fuse_do_setattr() returns w/o calling truncate_pagecache().
4. As soon as ftruncate(2) completes, the user extends file size by
write(2) making a hole in the middle of file, then reads data from the hole
either by read(2) or mmap-ed read. The user expects to get zero data from
the hole, but gets stale data because truncate_pagecache() is not executed
yet.
The scenario above illustrates one side of the problem: not truncating the
page cache even though we should. Another side corresponds to truncating
page cache too late, when the state of inode changed significantly.
Theoretically, the following is possible:
1. As in the previous scenario fuse_dentry_revalidate() discovered that
i_size changed (due to our own fuse_do_setattr()) and is going to call
truncate_pagecache() for some 'new_size' it believes valid right now. But
by the time that particular truncate_pagecache() is called ...
2. fuse_do_setattr() returns (either having called truncate_pagecache() or
not -- it doesn't matter).
3. The file is extended either by write(2) or ftruncate(2) or fallocate(2).
4. mmap-ed write makes a page in the extended region dirty.
The result will be the lost of data user wrote on the fourth step.
The patch is a hotfix resolving the issue in a simplistic way: let's skip
dangerous i_size update and truncate_pagecache if an operation changing
file size is in progress. This simplistic approach looks correct for the
cases w/o external changes. And to handle them properly, more sophisticated
and intrusive techniques (e.g. NFS-like one) would be required. I'd like to
postpone it until the issue is well discussed on the mailing list(s).
Changed in v2:
- improved patch description to cover both sides of the issue.
Signed-off-by: Maxim Patlasov <mpatlasov@parallels.com>
Signed-off-by: Miklos Szeredi <mszeredi@suse.cz>
Cc: stable@vger.kernel.org
2013-08-30 13:06:04 +00:00
|
|
|
/** An operation changing file size is in progress */
|
|
|
|
FUSE_I_SIZE_UNSTABLE,
|
[PATCH] FUSE - core
This patch adds FUSE core.
This contains the following files:
o inode.c
- superblock operations (alloc_inode, destroy_inode, read_inode,
clear_inode, put_super, show_options)
- registers FUSE filesystem
o fuse_i.h
- private header file
Requirements
============
The most important difference between orinary filesystems and FUSE is
the fact, that the filesystem data/metadata is provided by a userspace
process run with the privileges of the mount "owner" instead of the
kernel, or some remote entity usually running with elevated
privileges.
The security implication of this is that a non-privileged user must
not be able to use this capability to compromise the system. Obvious
requirements arising from this are:
- mount owner should not be able to get elevated privileges with the
help of the mounted filesystem
- mount owner should not be able to induce undesired behavior in
other users' or the super user's processes
- mount owner should not get illegitimate access to information from
other users' and the super user's processes
These are currently ensured with the following constraints:
1) mount is only allowed to directory or file which the mount owner
can modify without limitation (write access + no sticky bit for
directories)
2) nosuid,nodev mount options are forced
3) any process running with fsuid different from the owner is denied
all access to the filesystem
1) and 2) are ensured by the "fusermount" mount utility which is a
setuid root application doing the actual mount operation.
3) is ensured by a check in the permission() method in kernel
I started thinking about doing 3) in a different way because Christoph
H. made a big deal out of it, saying that FUSE is unacceptable into
mainline in this form.
The suggested use of private namespaces would be OK, but in their
current form have many limitations that make their use impractical (as
discussed in this thread).
Suggested improvements that would address these limitations:
- implement shared subtrees
- allow a process to join an existing namespace (make namespaces
first-class objects)
- implement the namespace creation/joining in a PAM module
With all that in place the check of owner against current->fsuid may
be removed from the FUSE kernel module, without compromising the
security requirements.
Suid programs still interesting questions, since they get access even
to the private namespace causing some information leak (exact
order/timing of filesystem operations performed), giving some
ptrace-like capabilities to unprivileged users. BTW this problem is
not strictly limited to the namespace approach, since suid programs
setting fsuid and accessing users' files will succeed with the current
approach too.
Signed-off-by: Miklos Szeredi <miklos@szeredi.hu>
Signed-off-by: Andrew Morton <akpm@osdl.org>
Signed-off-by: Linus Torvalds <torvalds@osdl.org>
2005-09-09 20:10:26 +00:00
|
|
|
};
|
|
|
|
|
2009-04-28 14:56:36 +00:00
|
|
|
struct fuse_conn;
|
|
|
|
|
2005-09-09 20:10:30 +00:00
|
|
|
/** FUSE specific file data */
|
|
|
|
struct fuse_file {
|
2009-04-28 14:56:36 +00:00
|
|
|
/** Fuse connection for this file */
|
|
|
|
struct fuse_conn *fc;
|
|
|
|
|
2005-09-09 20:10:30 +00:00
|
|
|
/** Request reserved for flush and release */
|
2006-06-25 12:48:52 +00:00
|
|
|
struct fuse_req *reserved_req;
|
2005-09-09 20:10:30 +00:00
|
|
|
|
2008-11-26 11:03:55 +00:00
|
|
|
/** Kernel file handle guaranteed to be unique */
|
|
|
|
u64 kh;
|
|
|
|
|
2005-09-09 20:10:30 +00:00
|
|
|
/** File handle used by userspace */
|
|
|
|
u64 fh;
|
2007-10-17 06:31:00 +00:00
|
|
|
|
2009-04-28 14:56:36 +00:00
|
|
|
/** Node id of this file */
|
|
|
|
u64 nodeid;
|
|
|
|
|
2007-10-17 06:31:00 +00:00
|
|
|
/** Refcount */
|
|
|
|
atomic_t count;
|
2007-10-18 10:07:03 +00:00
|
|
|
|
2009-04-28 14:56:37 +00:00
|
|
|
/** FOPEN_* flags returned by open */
|
|
|
|
u32 open_flags;
|
|
|
|
|
2007-10-18 10:07:03 +00:00
|
|
|
/** Entry on inode's write_files list */
|
|
|
|
struct list_head write_entry;
|
2008-11-26 11:03:55 +00:00
|
|
|
|
|
|
|
/** RB node to be linked on fuse_conn->polled_files */
|
|
|
|
struct rb_node polled_node;
|
|
|
|
|
|
|
|
/** Wait queue head for poll */
|
|
|
|
wait_queue_head_t poll_wait;
|
2011-08-08 14:08:08 +00:00
|
|
|
|
|
|
|
/** Has flock been performed on this file? */
|
|
|
|
bool flock:1;
|
2005-09-09 20:10:30 +00:00
|
|
|
};
|
|
|
|
|
2005-09-09 20:10:27 +00:00
|
|
|
/** One input argument of a request */
|
|
|
|
struct fuse_in_arg {
|
|
|
|
unsigned size;
|
|
|
|
const void *value;
|
|
|
|
};
|
|
|
|
|
|
|
|
/** The request input */
|
|
|
|
struct fuse_in {
|
|
|
|
/** The request header */
|
|
|
|
struct fuse_in_header h;
|
|
|
|
|
|
|
|
/** True if the data for the last argument is in req->pages */
|
|
|
|
unsigned argpages:1;
|
|
|
|
|
|
|
|
/** Number of arguments */
|
|
|
|
unsigned numargs;
|
|
|
|
|
|
|
|
/** Array of arguments */
|
|
|
|
struct fuse_in_arg args[3];
|
|
|
|
};
|
|
|
|
|
|
|
|
/** One output argument of a request */
|
|
|
|
struct fuse_arg {
|
|
|
|
unsigned size;
|
|
|
|
void *value;
|
|
|
|
};
|
|
|
|
|
|
|
|
/** The request output */
|
|
|
|
struct fuse_out {
|
|
|
|
/** Header returned from userspace */
|
|
|
|
struct fuse_out_header h;
|
|
|
|
|
2006-01-17 06:14:52 +00:00
|
|
|
/*
|
|
|
|
* The following bitfields are not changed during the request
|
|
|
|
* processing
|
|
|
|
*/
|
|
|
|
|
2005-09-09 20:10:27 +00:00
|
|
|
/** Last argument is variable length (can be shorter than
|
|
|
|
arg->size) */
|
|
|
|
unsigned argvar:1;
|
|
|
|
|
|
|
|
/** Last argument is a list of pages to copy data to */
|
|
|
|
unsigned argpages:1;
|
|
|
|
|
|
|
|
/** Zero partially or not copied pages */
|
|
|
|
unsigned page_zeroing:1;
|
|
|
|
|
2010-05-25 13:06:07 +00:00
|
|
|
/** Pages may be replaced with new ones */
|
|
|
|
unsigned page_replace:1;
|
|
|
|
|
2005-09-09 20:10:27 +00:00
|
|
|
/** Number or arguments */
|
|
|
|
unsigned numargs;
|
|
|
|
|
|
|
|
/** Array of arguments */
|
|
|
|
struct fuse_arg args[3];
|
|
|
|
};
|
|
|
|
|
2012-10-26 15:49:24 +00:00
|
|
|
/** FUSE page descriptor */
|
|
|
|
struct fuse_page_desc {
|
|
|
|
unsigned int length;
|
|
|
|
unsigned int offset;
|
|
|
|
};
|
|
|
|
|
2006-01-17 06:14:31 +00:00
|
|
|
/** The request state */
|
|
|
|
enum fuse_req_state {
|
|
|
|
FUSE_REQ_INIT = 0,
|
|
|
|
FUSE_REQ_PENDING,
|
|
|
|
FUSE_REQ_READING,
|
|
|
|
FUSE_REQ_SENT,
|
2006-06-25 12:48:54 +00:00
|
|
|
FUSE_REQ_WRITING,
|
2006-01-17 06:14:31 +00:00
|
|
|
FUSE_REQ_FINISHED
|
|
|
|
};
|
|
|
|
|
2012-12-14 15:20:41 +00:00
|
|
|
/** The request IO state (for asynchronous processing) */
|
|
|
|
struct fuse_io_priv {
|
|
|
|
int async;
|
|
|
|
spinlock_t lock;
|
|
|
|
unsigned reqs;
|
|
|
|
ssize_t bytes;
|
|
|
|
size_t size;
|
|
|
|
__u64 offset;
|
|
|
|
bool write;
|
|
|
|
int err;
|
|
|
|
struct kiocb *iocb;
|
|
|
|
struct file *file;
|
|
|
|
};
|
|
|
|
|
2005-09-09 20:10:27 +00:00
|
|
|
/**
|
|
|
|
* A request to the client
|
|
|
|
*/
|
|
|
|
struct fuse_req {
|
2006-04-11 05:54:58 +00:00
|
|
|
/** This can be on either pending processing or io lists in
|
|
|
|
fuse_conn */
|
2005-09-09 20:10:27 +00:00
|
|
|
struct list_head list;
|
|
|
|
|
2006-06-25 12:48:54 +00:00
|
|
|
/** Entry on the interrupts list */
|
|
|
|
struct list_head intr_entry;
|
|
|
|
|
2005-09-09 20:10:27 +00:00
|
|
|
/** refcount */
|
|
|
|
atomic_t count;
|
|
|
|
|
2006-06-25 12:48:54 +00:00
|
|
|
/** Unique ID for the interrupt request */
|
|
|
|
u64 intr_unique;
|
|
|
|
|
2006-01-17 06:14:52 +00:00
|
|
|
/*
|
|
|
|
* The following bitfields are either set once before the
|
|
|
|
* request is queued or setting/clearing them is protected by
|
2006-04-11 05:54:55 +00:00
|
|
|
* fuse_conn->lock
|
2006-01-17 06:14:52 +00:00
|
|
|
*/
|
|
|
|
|
2005-09-09 20:10:27 +00:00
|
|
|
/** True if the request has reply */
|
|
|
|
unsigned isreply:1;
|
|
|
|
|
2006-06-25 12:48:50 +00:00
|
|
|
/** Force sending of the request even if interrupted */
|
|
|
|
unsigned force:1;
|
|
|
|
|
2006-06-25 12:48:53 +00:00
|
|
|
/** The request was aborted */
|
|
|
|
unsigned aborted:1;
|
2005-09-09 20:10:27 +00:00
|
|
|
|
|
|
|
/** Request is sent in the background */
|
|
|
|
unsigned background:1;
|
|
|
|
|
2006-06-25 12:48:54 +00:00
|
|
|
/** The request has been interrupted */
|
|
|
|
unsigned interrupted:1;
|
|
|
|
|
2005-09-09 20:10:27 +00:00
|
|
|
/** Data is being copied to/from the request */
|
|
|
|
unsigned locked:1;
|
|
|
|
|
2006-04-11 19:16:09 +00:00
|
|
|
/** Request is counted as "waiting" */
|
|
|
|
unsigned waiting:1;
|
|
|
|
|
2006-01-17 06:14:31 +00:00
|
|
|
/** State of the request */
|
|
|
|
enum fuse_req_state state;
|
2005-09-09 20:10:27 +00:00
|
|
|
|
|
|
|
/** The request input */
|
|
|
|
struct fuse_in in;
|
|
|
|
|
|
|
|
/** The request output */
|
|
|
|
struct fuse_out out;
|
|
|
|
|
|
|
|
/** Used to wake up the task waiting for completion of request*/
|
|
|
|
wait_queue_head_t waitq;
|
|
|
|
|
|
|
|
/** Data for asynchronous requests */
|
|
|
|
union {
|
2008-02-06 09:38:39 +00:00
|
|
|
struct {
|
2011-02-25 13:44:58 +00:00
|
|
|
union {
|
|
|
|
struct fuse_release_in in;
|
|
|
|
struct work_struct work;
|
|
|
|
};
|
2009-04-28 14:56:36 +00:00
|
|
|
struct path path;
|
2008-02-06 09:38:39 +00:00
|
|
|
} release;
|
2006-01-06 08:19:41 +00:00
|
|
|
struct fuse_init_in init_in;
|
|
|
|
struct fuse_init_out init_out;
|
2009-04-14 01:54:53 +00:00
|
|
|
struct cuse_init_in cuse_init_in;
|
2008-04-30 07:54:43 +00:00
|
|
|
struct {
|
|
|
|
struct fuse_read_in in;
|
|
|
|
u64 attr_ver;
|
|
|
|
} read;
|
2007-10-18 10:07:03 +00:00
|
|
|
struct {
|
|
|
|
struct fuse_write_in in;
|
|
|
|
struct fuse_write_out out;
|
2013-10-01 14:44:53 +00:00
|
|
|
struct fuse_req *next;
|
2007-10-18 10:07:03 +00:00
|
|
|
} write;
|
2010-07-12 12:41:40 +00:00
|
|
|
struct fuse_notify_retrieve_in retrieve_in;
|
2006-06-25 12:48:52 +00:00
|
|
|
struct fuse_lk_in lk_in;
|
2005-09-09 20:10:27 +00:00
|
|
|
} misc;
|
|
|
|
|
|
|
|
/** page vector */
|
2012-10-26 15:48:07 +00:00
|
|
|
struct page **pages;
|
|
|
|
|
2012-10-26 15:49:24 +00:00
|
|
|
/** page-descriptor vector */
|
|
|
|
struct fuse_page_desc *page_descs;
|
|
|
|
|
2012-10-26 15:48:07 +00:00
|
|
|
/** size of the 'pages' array */
|
|
|
|
unsigned max_pages;
|
|
|
|
|
|
|
|
/** inline page vector */
|
|
|
|
struct page *inline_pages[FUSE_REQ_INLINE_PAGES];
|
2005-09-09 20:10:27 +00:00
|
|
|
|
2012-10-26 15:49:24 +00:00
|
|
|
/** inline page-descriptor vector */
|
|
|
|
struct fuse_page_desc inline_page_descs[FUSE_REQ_INLINE_PAGES];
|
|
|
|
|
2005-09-09 20:10:27 +00:00
|
|
|
/** number of pages in vector */
|
|
|
|
unsigned num_pages;
|
|
|
|
|
|
|
|
/** File used in the request (or NULL) */
|
2007-10-17 06:31:00 +00:00
|
|
|
struct fuse_file *ff;
|
2006-01-17 06:14:42 +00:00
|
|
|
|
fuse: support writable mmap
Quoting Linus (3 years ago, FUSE inclusion discussions):
"User-space filesystems are hard to get right. I'd claim that they
are almost impossible, unless you limit them somehow (shared
writable mappings are the nastiest part - if you don't have those,
you can reasonably limit your problems by limiting the number of
dirty pages you accept through normal "write()" calls)."
Instead of attempting the impossible, I've just waited for the dirty page
accounting infrastructure to materialize (thanks to Peter Zijlstra and
others). This nicely solved the biggest problem: limiting the number of pages
used for write caching.
Some small details remained, however, which this largish patch attempts to
address. It provides a page writeback implementation for fuse, which is
completely safe against VM related deadlocks. Performance may not be very
good for certain usage patterns, but generally it should be acceptable.
It has been tested extensively with fsx-linux and bash-shared-mapping.
Fuse page writeback design
--------------------------
fuse_writepage() allocates a new temporary page with GFP_NOFS|__GFP_HIGHMEM.
It copies the contents of the original page, and queues a WRITE request to the
userspace filesystem using this temp page.
The writeback is finished instantly from the MM's point of view: the page is
removed from the radix trees, and the PageDirty and PageWriteback flags are
cleared.
For the duration of the actual write, the NR_WRITEBACK_TEMP counter is
incremented. The per-bdi writeback count is not decremented until the actual
write completes.
On dirtying the page, fuse waits for a previous write to finish before
proceeding. This makes sure, there can only be one temporary page used at a
time for one cached page.
This approach is wasteful in both memory and CPU bandwidth, so why is this
complication needed?
The basic problem is that there can be no guarantee about the time in which
the userspace filesystem will complete a write. It may be buggy or even
malicious, and fail to complete WRITE requests. We don't want unrelated parts
of the system to grind to a halt in such cases.
Also a filesystem may need additional resources (particularly memory) to
complete a WRITE request. There's a great danger of a deadlock if that
allocation may wait for the writepage to finish.
Currently there are several cases where the kernel can block on page
writeback:
- allocation order is larger than PAGE_ALLOC_COSTLY_ORDER
- page migration
- throttle_vm_writeout (through NR_WRITEBACK)
- sync(2)
Of course in some cases (fsync, msync) we explicitly want to allow blocking.
So for these cases new code has to be added to fuse, since the VM is not
tracking writeback pages for us any more.
As an extra safetly measure, the maximum dirty ratio allocated to a single
fuse filesystem is set to 1% by default. This way one (or several) buggy or
malicious fuse filesystems cannot slow down the rest of the system by hogging
dirty memory.
With appropriate privileges, this limit can be raised through
'/sys/class/bdi/<bdi>/max_ratio'.
Signed-off-by: Miklos Szeredi <mszeredi@suse.cz>
Cc: Peter Zijlstra <a.p.zijlstra@chello.nl>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
2008-04-30 07:54:41 +00:00
|
|
|
/** Inode used in the request or NULL */
|
|
|
|
struct inode *inode;
|
|
|
|
|
2012-12-14 15:20:41 +00:00
|
|
|
/** AIO control block */
|
|
|
|
struct fuse_io_priv *io;
|
|
|
|
|
fuse: support writable mmap
Quoting Linus (3 years ago, FUSE inclusion discussions):
"User-space filesystems are hard to get right. I'd claim that they
are almost impossible, unless you limit them somehow (shared
writable mappings are the nastiest part - if you don't have those,
you can reasonably limit your problems by limiting the number of
dirty pages you accept through normal "write()" calls)."
Instead of attempting the impossible, I've just waited for the dirty page
accounting infrastructure to materialize (thanks to Peter Zijlstra and
others). This nicely solved the biggest problem: limiting the number of pages
used for write caching.
Some small details remained, however, which this largish patch attempts to
address. It provides a page writeback implementation for fuse, which is
completely safe against VM related deadlocks. Performance may not be very
good for certain usage patterns, but generally it should be acceptable.
It has been tested extensively with fsx-linux and bash-shared-mapping.
Fuse page writeback design
--------------------------
fuse_writepage() allocates a new temporary page with GFP_NOFS|__GFP_HIGHMEM.
It copies the contents of the original page, and queues a WRITE request to the
userspace filesystem using this temp page.
The writeback is finished instantly from the MM's point of view: the page is
removed from the radix trees, and the PageDirty and PageWriteback flags are
cleared.
For the duration of the actual write, the NR_WRITEBACK_TEMP counter is
incremented. The per-bdi writeback count is not decremented until the actual
write completes.
On dirtying the page, fuse waits for a previous write to finish before
proceeding. This makes sure, there can only be one temporary page used at a
time for one cached page.
This approach is wasteful in both memory and CPU bandwidth, so why is this
complication needed?
The basic problem is that there can be no guarantee about the time in which
the userspace filesystem will complete a write. It may be buggy or even
malicious, and fail to complete WRITE requests. We don't want unrelated parts
of the system to grind to a halt in such cases.
Also a filesystem may need additional resources (particularly memory) to
complete a WRITE request. There's a great danger of a deadlock if that
allocation may wait for the writepage to finish.
Currently there are several cases where the kernel can block on page
writeback:
- allocation order is larger than PAGE_ALLOC_COSTLY_ORDER
- page migration
- throttle_vm_writeout (through NR_WRITEBACK)
- sync(2)
Of course in some cases (fsync, msync) we explicitly want to allow blocking.
So for these cases new code has to be added to fuse, since the VM is not
tracking writeback pages for us any more.
As an extra safetly measure, the maximum dirty ratio allocated to a single
fuse filesystem is set to 1% by default. This way one (or several) buggy or
malicious fuse filesystems cannot slow down the rest of the system by hogging
dirty memory.
With appropriate privileges, this limit can be raised through
'/sys/class/bdi/<bdi>/max_ratio'.
Signed-off-by: Miklos Szeredi <mszeredi@suse.cz>
Cc: Peter Zijlstra <a.p.zijlstra@chello.nl>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
2008-04-30 07:54:41 +00:00
|
|
|
/** Link on fi->writepages */
|
|
|
|
struct list_head writepages_entry;
|
|
|
|
|
2006-01-17 06:14:42 +00:00
|
|
|
/** Request completion callback */
|
|
|
|
void (*end)(struct fuse_conn *, struct fuse_req *);
|
2006-06-25 12:48:52 +00:00
|
|
|
|
|
|
|
/** Request is stolen from fuse_file->reserved_req */
|
|
|
|
struct file *stolen_file;
|
2005-09-09 20:10:27 +00:00
|
|
|
};
|
|
|
|
|
[PATCH] FUSE - core
This patch adds FUSE core.
This contains the following files:
o inode.c
- superblock operations (alloc_inode, destroy_inode, read_inode,
clear_inode, put_super, show_options)
- registers FUSE filesystem
o fuse_i.h
- private header file
Requirements
============
The most important difference between orinary filesystems and FUSE is
the fact, that the filesystem data/metadata is provided by a userspace
process run with the privileges of the mount "owner" instead of the
kernel, or some remote entity usually running with elevated
privileges.
The security implication of this is that a non-privileged user must
not be able to use this capability to compromise the system. Obvious
requirements arising from this are:
- mount owner should not be able to get elevated privileges with the
help of the mounted filesystem
- mount owner should not be able to induce undesired behavior in
other users' or the super user's processes
- mount owner should not get illegitimate access to information from
other users' and the super user's processes
These are currently ensured with the following constraints:
1) mount is only allowed to directory or file which the mount owner
can modify without limitation (write access + no sticky bit for
directories)
2) nosuid,nodev mount options are forced
3) any process running with fsuid different from the owner is denied
all access to the filesystem
1) and 2) are ensured by the "fusermount" mount utility which is a
setuid root application doing the actual mount operation.
3) is ensured by a check in the permission() method in kernel
I started thinking about doing 3) in a different way because Christoph
H. made a big deal out of it, saying that FUSE is unacceptable into
mainline in this form.
The suggested use of private namespaces would be OK, but in their
current form have many limitations that make their use impractical (as
discussed in this thread).
Suggested improvements that would address these limitations:
- implement shared subtrees
- allow a process to join an existing namespace (make namespaces
first-class objects)
- implement the namespace creation/joining in a PAM module
With all that in place the check of owner against current->fsuid may
be removed from the FUSE kernel module, without compromising the
security requirements.
Suid programs still interesting questions, since they get access even
to the private namespace causing some information leak (exact
order/timing of filesystem operations performed), giving some
ptrace-like capabilities to unprivileged users. BTW this problem is
not strictly limited to the namespace approach, since suid programs
setting fsuid and accessing users' files will succeed with the current
approach too.
Signed-off-by: Miklos Szeredi <miklos@szeredi.hu>
Signed-off-by: Andrew Morton <akpm@osdl.org>
Signed-off-by: Linus Torvalds <torvalds@osdl.org>
2005-09-09 20:10:26 +00:00
|
|
|
/**
|
|
|
|
* A Fuse connection.
|
|
|
|
*
|
|
|
|
* This structure is created, when the filesystem is mounted, and is
|
|
|
|
* destroyed, when the client device is closed and the filesystem is
|
|
|
|
* unmounted.
|
|
|
|
*/
|
|
|
|
struct fuse_conn {
|
2006-04-11 05:54:55 +00:00
|
|
|
/** Lock protecting accessess to members of this structure */
|
|
|
|
spinlock_t lock;
|
|
|
|
|
2006-06-25 12:48:51 +00:00
|
|
|
/** Refcount */
|
|
|
|
atomic_t count;
|
|
|
|
|
2013-10-04 01:21:39 +00:00
|
|
|
struct rcu_head rcu;
|
|
|
|
|
[PATCH] FUSE - core
This patch adds FUSE core.
This contains the following files:
o inode.c
- superblock operations (alloc_inode, destroy_inode, read_inode,
clear_inode, put_super, show_options)
- registers FUSE filesystem
o fuse_i.h
- private header file
Requirements
============
The most important difference between orinary filesystems and FUSE is
the fact, that the filesystem data/metadata is provided by a userspace
process run with the privileges of the mount "owner" instead of the
kernel, or some remote entity usually running with elevated
privileges.
The security implication of this is that a non-privileged user must
not be able to use this capability to compromise the system. Obvious
requirements arising from this are:
- mount owner should not be able to get elevated privileges with the
help of the mounted filesystem
- mount owner should not be able to induce undesired behavior in
other users' or the super user's processes
- mount owner should not get illegitimate access to information from
other users' and the super user's processes
These are currently ensured with the following constraints:
1) mount is only allowed to directory or file which the mount owner
can modify without limitation (write access + no sticky bit for
directories)
2) nosuid,nodev mount options are forced
3) any process running with fsuid different from the owner is denied
all access to the filesystem
1) and 2) are ensured by the "fusermount" mount utility which is a
setuid root application doing the actual mount operation.
3) is ensured by a check in the permission() method in kernel
I started thinking about doing 3) in a different way because Christoph
H. made a big deal out of it, saying that FUSE is unacceptable into
mainline in this form.
The suggested use of private namespaces would be OK, but in their
current form have many limitations that make their use impractical (as
discussed in this thread).
Suggested improvements that would address these limitations:
- implement shared subtrees
- allow a process to join an existing namespace (make namespaces
first-class objects)
- implement the namespace creation/joining in a PAM module
With all that in place the check of owner against current->fsuid may
be removed from the FUSE kernel module, without compromising the
security requirements.
Suid programs still interesting questions, since they get access even
to the private namespace causing some information leak (exact
order/timing of filesystem operations performed), giving some
ptrace-like capabilities to unprivileged users. BTW this problem is
not strictly limited to the namespace approach, since suid programs
setting fsuid and accessing users' files will succeed with the current
approach too.
Signed-off-by: Miklos Szeredi <miklos@szeredi.hu>
Signed-off-by: Andrew Morton <akpm@osdl.org>
Signed-off-by: Linus Torvalds <torvalds@osdl.org>
2005-09-09 20:10:26 +00:00
|
|
|
/** The user id for this mount */
|
2012-02-08 00:26:03 +00:00
|
|
|
kuid_t user_id;
|
[PATCH] FUSE - core
This patch adds FUSE core.
This contains the following files:
o inode.c
- superblock operations (alloc_inode, destroy_inode, read_inode,
clear_inode, put_super, show_options)
- registers FUSE filesystem
o fuse_i.h
- private header file
Requirements
============
The most important difference between orinary filesystems and FUSE is
the fact, that the filesystem data/metadata is provided by a userspace
process run with the privileges of the mount "owner" instead of the
kernel, or some remote entity usually running with elevated
privileges.
The security implication of this is that a non-privileged user must
not be able to use this capability to compromise the system. Obvious
requirements arising from this are:
- mount owner should not be able to get elevated privileges with the
help of the mounted filesystem
- mount owner should not be able to induce undesired behavior in
other users' or the super user's processes
- mount owner should not get illegitimate access to information from
other users' and the super user's processes
These are currently ensured with the following constraints:
1) mount is only allowed to directory or file which the mount owner
can modify without limitation (write access + no sticky bit for
directories)
2) nosuid,nodev mount options are forced
3) any process running with fsuid different from the owner is denied
all access to the filesystem
1) and 2) are ensured by the "fusermount" mount utility which is a
setuid root application doing the actual mount operation.
3) is ensured by a check in the permission() method in kernel
I started thinking about doing 3) in a different way because Christoph
H. made a big deal out of it, saying that FUSE is unacceptable into
mainline in this form.
The suggested use of private namespaces would be OK, but in their
current form have many limitations that make their use impractical (as
discussed in this thread).
Suggested improvements that would address these limitations:
- implement shared subtrees
- allow a process to join an existing namespace (make namespaces
first-class objects)
- implement the namespace creation/joining in a PAM module
With all that in place the check of owner against current->fsuid may
be removed from the FUSE kernel module, without compromising the
security requirements.
Suid programs still interesting questions, since they get access even
to the private namespace causing some information leak (exact
order/timing of filesystem operations performed), giving some
ptrace-like capabilities to unprivileged users. BTW this problem is
not strictly limited to the namespace approach, since suid programs
setting fsuid and accessing users' files will succeed with the current
approach too.
Signed-off-by: Miklos Szeredi <miklos@szeredi.hu>
Signed-off-by: Andrew Morton <akpm@osdl.org>
Signed-off-by: Linus Torvalds <torvalds@osdl.org>
2005-09-09 20:10:26 +00:00
|
|
|
|
2005-09-09 20:10:34 +00:00
|
|
|
/** The group id for this mount */
|
2012-02-08 00:26:03 +00:00
|
|
|
kgid_t group_id;
|
2005-09-09 20:10:34 +00:00
|
|
|
|
2005-09-09 20:10:31 +00:00
|
|
|
/** The fuse mount flags for this mount */
|
|
|
|
unsigned flags;
|
|
|
|
|
2005-09-09 20:10:33 +00:00
|
|
|
/** Maximum read size */
|
|
|
|
unsigned max_read;
|
|
|
|
|
2005-09-09 20:10:35 +00:00
|
|
|
/** Maximum write size */
|
|
|
|
unsigned max_write;
|
|
|
|
|
2005-09-09 20:10:27 +00:00
|
|
|
/** Readers of the connection are waiting on this */
|
|
|
|
wait_queue_head_t waitq;
|
|
|
|
|
|
|
|
/** The list of pending requests */
|
|
|
|
struct list_head pending;
|
|
|
|
|
|
|
|
/** The list of requests being processed */
|
|
|
|
struct list_head processing;
|
|
|
|
|
2006-01-17 06:14:31 +00:00
|
|
|
/** The list of requests under I/O */
|
|
|
|
struct list_head io;
|
|
|
|
|
2008-11-26 11:03:55 +00:00
|
|
|
/** The next unique kernel file handle */
|
|
|
|
u64 khctr;
|
|
|
|
|
2008-11-26 11:03:55 +00:00
|
|
|
/** rbtree of fuse_files waiting for poll events indexed by ph */
|
|
|
|
struct rb_root polled_files;
|
|
|
|
|
2009-07-02 00:28:41 +00:00
|
|
|
/** Maximum number of outstanding background requests */
|
|
|
|
unsigned max_background;
|
|
|
|
|
|
|
|
/** Number of background requests at which congestion starts */
|
|
|
|
unsigned congestion_threshold;
|
|
|
|
|
2006-04-11 05:54:59 +00:00
|
|
|
/** Number of requests currently in the background */
|
|
|
|
unsigned num_background;
|
|
|
|
|
2008-02-06 09:38:39 +00:00
|
|
|
/** Number of background requests currently queued for userspace */
|
|
|
|
unsigned active_background;
|
|
|
|
|
|
|
|
/** The list of background requests set aside for later queuing */
|
|
|
|
struct list_head bg_queue;
|
|
|
|
|
2006-06-25 12:48:54 +00:00
|
|
|
/** Pending interrupts */
|
|
|
|
struct list_head interrupts;
|
|
|
|
|
2010-12-07 19:16:56 +00:00
|
|
|
/** Queue of pending forgets */
|
|
|
|
struct fuse_forget_link forget_list_head;
|
|
|
|
struct fuse_forget_link *forget_list_tail;
|
|
|
|
|
|
|
|
/** Batching of FORGET requests (positive indicates FORGET batch) */
|
|
|
|
int forget_batch;
|
|
|
|
|
2013-03-21 14:02:15 +00:00
|
|
|
/** Flag indicating that INIT reply has been received. Allocating
|
|
|
|
* any fuse request will be suspended until the flag is set */
|
|
|
|
int initialized;
|
|
|
|
|
2006-04-11 05:54:59 +00:00
|
|
|
/** Flag indicating if connection is blocked. This will be
|
|
|
|
the case before the INIT reply is received, and if there
|
|
|
|
are too many outstading backgrounds requests */
|
|
|
|
int blocked;
|
|
|
|
|
|
|
|
/** waitq for blocked connection */
|
|
|
|
wait_queue_head_t blocked_waitq;
|
2007-10-17 06:31:00 +00:00
|
|
|
|
|
|
|
/** waitq for reserved requests */
|
|
|
|
wait_queue_head_t reserved_req_waitq;
|
2006-04-11 05:54:59 +00:00
|
|
|
|
2005-09-09 20:10:27 +00:00
|
|
|
/** The next unique request id */
|
|
|
|
u64 reqctr;
|
|
|
|
|
2006-01-17 06:14:41 +00:00
|
|
|
/** Connection established, cleared on umount, connection
|
|
|
|
abort and device release */
|
2006-01-17 06:14:52 +00:00
|
|
|
unsigned connected;
|
2005-09-09 20:10:31 +00:00
|
|
|
|
2006-01-17 06:14:52 +00:00
|
|
|
/** Connection failed (version mismatch). Cannot race with
|
|
|
|
setting other bitfields since it is only set once in INIT
|
|
|
|
reply, before any other request, and never cleared */
|
2008-11-26 11:03:54 +00:00
|
|
|
unsigned conn_error:1;
|
2005-09-09 20:10:27 +00:00
|
|
|
|
2006-12-07 04:35:52 +00:00
|
|
|
/** Connection successful. Only set in INIT */
|
2008-11-26 11:03:54 +00:00
|
|
|
unsigned conn_init:1;
|
2006-12-07 04:35:52 +00:00
|
|
|
|
2006-02-01 11:04:40 +00:00
|
|
|
/** Do readpages asynchronously? Only set in INIT */
|
2008-11-26 11:03:54 +00:00
|
|
|
unsigned async_read:1;
|
2006-02-01 11:04:40 +00:00
|
|
|
|
2007-10-18 10:07:02 +00:00
|
|
|
/** Do not send separate SETATTR request before open(O_TRUNC) */
|
2008-11-26 11:03:54 +00:00
|
|
|
unsigned atomic_o_trunc:1;
|
2007-10-18 10:07:02 +00:00
|
|
|
|
2008-07-25 08:49:02 +00:00
|
|
|
/** Filesystem supports NFS exporting. Only set in INIT */
|
2008-11-26 11:03:54 +00:00
|
|
|
unsigned export_support:1;
|
2008-07-25 08:49:02 +00:00
|
|
|
|
2009-04-14 01:54:52 +00:00
|
|
|
/** Set if bdi is valid */
|
|
|
|
unsigned bdi_initialized:1;
|
|
|
|
|
2006-01-17 06:14:52 +00:00
|
|
|
/*
|
|
|
|
* The following bitfields are only for optimization purposes
|
|
|
|
* and hence races in setting them will not cause malfunction
|
|
|
|
*/
|
|
|
|
|
2005-09-09 20:10:30 +00:00
|
|
|
/** Is fsync not implemented by fs? */
|
2008-11-26 11:03:54 +00:00
|
|
|
unsigned no_fsync:1;
|
2005-09-09 20:10:30 +00:00
|
|
|
|
2005-09-09 20:10:38 +00:00
|
|
|
/** Is fsyncdir not implemented by fs? */
|
2008-11-26 11:03:54 +00:00
|
|
|
unsigned no_fsyncdir:1;
|
2005-09-09 20:10:38 +00:00
|
|
|
|
2005-09-09 20:10:30 +00:00
|
|
|
/** Is flush not implemented by fs? */
|
2008-11-26 11:03:54 +00:00
|
|
|
unsigned no_flush:1;
|
2005-09-09 20:10:30 +00:00
|
|
|
|
2005-09-09 20:10:31 +00:00
|
|
|
/** Is setxattr not implemented by fs? */
|
2008-11-26 11:03:54 +00:00
|
|
|
unsigned no_setxattr:1;
|
2005-09-09 20:10:31 +00:00
|
|
|
|
|
|
|
/** Is getxattr not implemented by fs? */
|
2008-11-26 11:03:54 +00:00
|
|
|
unsigned no_getxattr:1;
|
2005-09-09 20:10:31 +00:00
|
|
|
|
|
|
|
/** Is listxattr not implemented by fs? */
|
2008-11-26 11:03:54 +00:00
|
|
|
unsigned no_listxattr:1;
|
2005-09-09 20:10:31 +00:00
|
|
|
|
|
|
|
/** Is removexattr not implemented by fs? */
|
2008-11-26 11:03:54 +00:00
|
|
|
unsigned no_removexattr:1;
|
2005-09-09 20:10:31 +00:00
|
|
|
|
2011-08-08 14:08:08 +00:00
|
|
|
/** Are posix file locking primitives not implemented by fs? */
|
2008-11-26 11:03:54 +00:00
|
|
|
unsigned no_lock:1;
|
2006-06-25 12:48:52 +00:00
|
|
|
|
2005-11-07 08:59:50 +00:00
|
|
|
/** Is access not implemented by fs? */
|
2008-11-26 11:03:54 +00:00
|
|
|
unsigned no_access:1;
|
2005-11-07 08:59:50 +00:00
|
|
|
|
2005-11-07 08:59:51 +00:00
|
|
|
/** Is create not implemented by fs? */
|
2008-11-26 11:03:54 +00:00
|
|
|
unsigned no_create:1;
|
2005-11-07 08:59:51 +00:00
|
|
|
|
2006-06-25 12:48:54 +00:00
|
|
|
/** Is interrupt not implemented by fs? */
|
2008-11-26 11:03:54 +00:00
|
|
|
unsigned no_interrupt:1;
|
2006-06-25 12:48:54 +00:00
|
|
|
|
2006-12-07 04:35:51 +00:00
|
|
|
/** Is bmap not implemented by fs? */
|
2008-11-26 11:03:54 +00:00
|
|
|
unsigned no_bmap:1;
|
2006-12-07 04:35:51 +00:00
|
|
|
|
2008-11-26 11:03:55 +00:00
|
|
|
/** Is poll not implemented by fs? */
|
|
|
|
unsigned no_poll:1;
|
|
|
|
|
2008-05-12 21:02:32 +00:00
|
|
|
/** Do multi-page cached writes */
|
2008-11-26 11:03:54 +00:00
|
|
|
unsigned big_writes:1;
|
2008-05-12 21:02:32 +00:00
|
|
|
|
2009-06-30 18:12:23 +00:00
|
|
|
/** Don't apply umask to creation modes */
|
|
|
|
unsigned dont_mask:1;
|
|
|
|
|
2011-08-08 14:08:08 +00:00
|
|
|
/** Are BSD file locking primitives not implemented by fs? */
|
|
|
|
unsigned no_flock:1;
|
|
|
|
|
2012-04-26 08:56:36 +00:00
|
|
|
/** Is fallocate not implemented by fs? */
|
|
|
|
unsigned no_fallocate:1;
|
|
|
|
|
2012-07-16 19:23:48 +00:00
|
|
|
/** Use enhanced/automatic page cache invalidation. */
|
|
|
|
unsigned auto_inval_data:1;
|
|
|
|
|
2013-02-06 22:29:01 +00:00
|
|
|
/** Does the filesystem support readdirplus? */
|
2012-08-19 12:53:23 +00:00
|
|
|
unsigned do_readdirplus:1;
|
|
|
|
|
2013-02-06 22:29:01 +00:00
|
|
|
/** Does the filesystem want adaptive readdirplus? */
|
|
|
|
unsigned readdirplus_auto:1;
|
|
|
|
|
2013-05-01 12:37:21 +00:00
|
|
|
/** Does the filesystem support asynchronous direct-IO submission? */
|
|
|
|
unsigned async_dio:1;
|
|
|
|
|
2006-01-17 06:14:38 +00:00
|
|
|
/** The number of requests waiting for completion */
|
|
|
|
atomic_t num_waiting;
|
|
|
|
|
2006-01-06 08:19:36 +00:00
|
|
|
/** Negotiated minor version */
|
|
|
|
unsigned minor;
|
|
|
|
|
[PATCH] FUSE - core
This patch adds FUSE core.
This contains the following files:
o inode.c
- superblock operations (alloc_inode, destroy_inode, read_inode,
clear_inode, put_super, show_options)
- registers FUSE filesystem
o fuse_i.h
- private header file
Requirements
============
The most important difference between orinary filesystems and FUSE is
the fact, that the filesystem data/metadata is provided by a userspace
process run with the privileges of the mount "owner" instead of the
kernel, or some remote entity usually running with elevated
privileges.
The security implication of this is that a non-privileged user must
not be able to use this capability to compromise the system. Obvious
requirements arising from this are:
- mount owner should not be able to get elevated privileges with the
help of the mounted filesystem
- mount owner should not be able to induce undesired behavior in
other users' or the super user's processes
- mount owner should not get illegitimate access to information from
other users' and the super user's processes
These are currently ensured with the following constraints:
1) mount is only allowed to directory or file which the mount owner
can modify without limitation (write access + no sticky bit for
directories)
2) nosuid,nodev mount options are forced
3) any process running with fsuid different from the owner is denied
all access to the filesystem
1) and 2) are ensured by the "fusermount" mount utility which is a
setuid root application doing the actual mount operation.
3) is ensured by a check in the permission() method in kernel
I started thinking about doing 3) in a different way because Christoph
H. made a big deal out of it, saying that FUSE is unacceptable into
mainline in this form.
The suggested use of private namespaces would be OK, but in their
current form have many limitations that make their use impractical (as
discussed in this thread).
Suggested improvements that would address these limitations:
- implement shared subtrees
- allow a process to join an existing namespace (make namespaces
first-class objects)
- implement the namespace creation/joining in a PAM module
With all that in place the check of owner against current->fsuid may
be removed from the FUSE kernel module, without compromising the
security requirements.
Suid programs still interesting questions, since they get access even
to the private namespace causing some information leak (exact
order/timing of filesystem operations performed), giving some
ptrace-like capabilities to unprivileged users. BTW this problem is
not strictly limited to the namespace approach, since suid programs
setting fsuid and accessing users' files will succeed with the current
approach too.
Signed-off-by: Miklos Szeredi <miklos@szeredi.hu>
Signed-off-by: Andrew Morton <akpm@osdl.org>
Signed-off-by: Linus Torvalds <torvalds@osdl.org>
2005-09-09 20:10:26 +00:00
|
|
|
/** Backing dev info */
|
|
|
|
struct backing_dev_info bdi;
|
2006-01-17 06:14:35 +00:00
|
|
|
|
2006-06-25 12:48:51 +00:00
|
|
|
/** Entry on the fuse_conn_list */
|
|
|
|
struct list_head entry;
|
|
|
|
|
2008-04-30 07:54:34 +00:00
|
|
|
/** Device ID from super block */
|
|
|
|
dev_t dev;
|
2006-06-25 12:48:51 +00:00
|
|
|
|
|
|
|
/** Dentries in the control filesystem */
|
|
|
|
struct dentry *ctl_dentry[FUSE_CTL_NUM_DENTRIES];
|
|
|
|
|
|
|
|
/** number of dentries used in the above array */
|
|
|
|
int ctl_ndents;
|
2006-04-11 05:54:52 +00:00
|
|
|
|
|
|
|
/** O_ASYNC requests */
|
|
|
|
struct fasync_struct *fasync;
|
2006-06-25 12:48:55 +00:00
|
|
|
|
|
|
|
/** Key for lock owner ID scrambling */
|
|
|
|
u32 scramble_key[4];
|
2006-12-07 04:35:52 +00:00
|
|
|
|
|
|
|
/** Reserved request for the DESTROY message */
|
|
|
|
struct fuse_req *destroy_req;
|
fuse: fix race between getattr and write
Getattr and lookup operations can be running in parallel to attribute changing
operations, such as write and setattr.
This means, that if for example getattr was slower than a write, the cached
size attribute could be set to a stale value.
To prevent this race, introduce a per-filesystem attribute version counter.
This counter is incremented whenever cached attributes are modified, and the
incremented value stored in the inode.
Before storing new attributes in the cache, getattr and lookup check, using
the version number, whether the attributes have been modified during the
request's lifetime. If so, the returned attributes are not cached, because
they might be stale.
Thanks to Jakub Bogusz for the bug report and test program.
[akpm@linux-foundation.org: coding-style fixes]
Signed-off-by: Miklos Szeredi <mszeredi@suse.cz>
Cc: Jakub Bogusz <jakub.bogusz@gemius.pl>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
2007-10-18 10:06:58 +00:00
|
|
|
|
|
|
|
/** Version counter for attribute changes */
|
|
|
|
u64 attr_version;
|
2008-11-26 11:03:56 +00:00
|
|
|
|
|
|
|
/** Called on final put */
|
|
|
|
void (*release)(struct fuse_conn *);
|
2009-05-31 15:13:57 +00:00
|
|
|
|
|
|
|
/** Super block for this connection. */
|
|
|
|
struct super_block *sb;
|
|
|
|
|
|
|
|
/** Read/write semaphore to hold when accessing sb. */
|
|
|
|
struct rw_semaphore killsb;
|
[PATCH] FUSE - core
This patch adds FUSE core.
This contains the following files:
o inode.c
- superblock operations (alloc_inode, destroy_inode, read_inode,
clear_inode, put_super, show_options)
- registers FUSE filesystem
o fuse_i.h
- private header file
Requirements
============
The most important difference between orinary filesystems and FUSE is
the fact, that the filesystem data/metadata is provided by a userspace
process run with the privileges of the mount "owner" instead of the
kernel, or some remote entity usually running with elevated
privileges.
The security implication of this is that a non-privileged user must
not be able to use this capability to compromise the system. Obvious
requirements arising from this are:
- mount owner should not be able to get elevated privileges with the
help of the mounted filesystem
- mount owner should not be able to induce undesired behavior in
other users' or the super user's processes
- mount owner should not get illegitimate access to information from
other users' and the super user's processes
These are currently ensured with the following constraints:
1) mount is only allowed to directory or file which the mount owner
can modify without limitation (write access + no sticky bit for
directories)
2) nosuid,nodev mount options are forced
3) any process running with fsuid different from the owner is denied
all access to the filesystem
1) and 2) are ensured by the "fusermount" mount utility which is a
setuid root application doing the actual mount operation.
3) is ensured by a check in the permission() method in kernel
I started thinking about doing 3) in a different way because Christoph
H. made a big deal out of it, saying that FUSE is unacceptable into
mainline in this form.
The suggested use of private namespaces would be OK, but in their
current form have many limitations that make their use impractical (as
discussed in this thread).
Suggested improvements that would address these limitations:
- implement shared subtrees
- allow a process to join an existing namespace (make namespaces
first-class objects)
- implement the namespace creation/joining in a PAM module
With all that in place the check of owner against current->fsuid may
be removed from the FUSE kernel module, without compromising the
security requirements.
Suid programs still interesting questions, since they get access even
to the private namespace causing some information leak (exact
order/timing of filesystem operations performed), giving some
ptrace-like capabilities to unprivileged users. BTW this problem is
not strictly limited to the namespace approach, since suid programs
setting fsuid and accessing users' files will succeed with the current
approach too.
Signed-off-by: Miklos Szeredi <miklos@szeredi.hu>
Signed-off-by: Andrew Morton <akpm@osdl.org>
Signed-off-by: Linus Torvalds <torvalds@osdl.org>
2005-09-09 20:10:26 +00:00
|
|
|
};
|
|
|
|
|
|
|
|
static inline struct fuse_conn *get_fuse_conn_super(struct super_block *sb)
|
|
|
|
{
|
2006-01-17 06:14:29 +00:00
|
|
|
return sb->s_fs_info;
|
[PATCH] FUSE - core
This patch adds FUSE core.
This contains the following files:
o inode.c
- superblock operations (alloc_inode, destroy_inode, read_inode,
clear_inode, put_super, show_options)
- registers FUSE filesystem
o fuse_i.h
- private header file
Requirements
============
The most important difference between orinary filesystems and FUSE is
the fact, that the filesystem data/metadata is provided by a userspace
process run with the privileges of the mount "owner" instead of the
kernel, or some remote entity usually running with elevated
privileges.
The security implication of this is that a non-privileged user must
not be able to use this capability to compromise the system. Obvious
requirements arising from this are:
- mount owner should not be able to get elevated privileges with the
help of the mounted filesystem
- mount owner should not be able to induce undesired behavior in
other users' or the super user's processes
- mount owner should not get illegitimate access to information from
other users' and the super user's processes
These are currently ensured with the following constraints:
1) mount is only allowed to directory or file which the mount owner
can modify without limitation (write access + no sticky bit for
directories)
2) nosuid,nodev mount options are forced
3) any process running with fsuid different from the owner is denied
all access to the filesystem
1) and 2) are ensured by the "fusermount" mount utility which is a
setuid root application doing the actual mount operation.
3) is ensured by a check in the permission() method in kernel
I started thinking about doing 3) in a different way because Christoph
H. made a big deal out of it, saying that FUSE is unacceptable into
mainline in this form.
The suggested use of private namespaces would be OK, but in their
current form have many limitations that make their use impractical (as
discussed in this thread).
Suggested improvements that would address these limitations:
- implement shared subtrees
- allow a process to join an existing namespace (make namespaces
first-class objects)
- implement the namespace creation/joining in a PAM module
With all that in place the check of owner against current->fsuid may
be removed from the FUSE kernel module, without compromising the
security requirements.
Suid programs still interesting questions, since they get access even
to the private namespace causing some information leak (exact
order/timing of filesystem operations performed), giving some
ptrace-like capabilities to unprivileged users. BTW this problem is
not strictly limited to the namespace approach, since suid programs
setting fsuid and accessing users' files will succeed with the current
approach too.
Signed-off-by: Miklos Szeredi <miklos@szeredi.hu>
Signed-off-by: Andrew Morton <akpm@osdl.org>
Signed-off-by: Linus Torvalds <torvalds@osdl.org>
2005-09-09 20:10:26 +00:00
|
|
|
}
|
|
|
|
|
|
|
|
static inline struct fuse_conn *get_fuse_conn(struct inode *inode)
|
|
|
|
{
|
|
|
|
return get_fuse_conn_super(inode->i_sb);
|
|
|
|
}
|
|
|
|
|
|
|
|
static inline struct fuse_inode *get_fuse_inode(struct inode *inode)
|
|
|
|
{
|
|
|
|
return container_of(inode, struct fuse_inode, inode);
|
|
|
|
}
|
|
|
|
|
|
|
|
static inline u64 get_node_id(struct inode *inode)
|
|
|
|
{
|
|
|
|
return get_fuse_inode(inode)->nodeid;
|
|
|
|
}
|
|
|
|
|
2005-09-09 20:10:27 +00:00
|
|
|
/** Device operations */
|
2006-03-28 09:56:42 +00:00
|
|
|
extern const struct file_operations fuse_dev_operations;
|
2005-09-09 20:10:27 +00:00
|
|
|
|
2009-02-20 05:59:13 +00:00
|
|
|
extern const struct dentry_operations fuse_dentry_operations;
|
2008-07-25 08:49:00 +00:00
|
|
|
|
2009-05-31 15:13:57 +00:00
|
|
|
/**
|
|
|
|
* Inode to nodeid comparison.
|
|
|
|
*/
|
|
|
|
int fuse_inode_eq(struct inode *inode, void *_nodeidp);
|
|
|
|
|
2005-09-09 20:10:28 +00:00
|
|
|
/**
|
|
|
|
* Get a filled in inode
|
|
|
|
*/
|
2008-04-30 07:54:44 +00:00
|
|
|
struct inode *fuse_iget(struct super_block *sb, u64 nodeid,
|
fuse: fix race between getattr and write
Getattr and lookup operations can be running in parallel to attribute changing
operations, such as write and setattr.
This means, that if for example getattr was slower than a write, the cached
size attribute could be set to a stale value.
To prevent this race, introduce a per-filesystem attribute version counter.
This counter is incremented whenever cached attributes are modified, and the
incremented value stored in the inode.
Before storing new attributes in the cache, getattr and lookup check, using
the version number, whether the attributes have been modified during the
request's lifetime. If so, the returned attributes are not cached, because
they might be stale.
Thanks to Jakub Bogusz for the bug report and test program.
[akpm@linux-foundation.org: coding-style fixes]
Signed-off-by: Miklos Szeredi <mszeredi@suse.cz>
Cc: Jakub Bogusz <jakub.bogusz@gemius.pl>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
2007-10-18 10:06:58 +00:00
|
|
|
int generation, struct fuse_attr *attr,
|
|
|
|
u64 attr_valid, u64 attr_version);
|
2005-09-09 20:10:28 +00:00
|
|
|
|
2008-07-25 08:49:02 +00:00
|
|
|
int fuse_lookup_name(struct super_block *sb, u64 nodeid, struct qstr *name,
|
|
|
|
struct fuse_entry_out *outarg, struct inode **inode);
|
|
|
|
|
2005-09-09 20:10:28 +00:00
|
|
|
/**
|
|
|
|
* Send FORGET command
|
|
|
|
*/
|
2010-12-07 19:16:56 +00:00
|
|
|
void fuse_queue_forget(struct fuse_conn *fc, struct fuse_forget_link *forget,
|
|
|
|
u64 nodeid, u64 nlookup);
|
|
|
|
|
|
|
|
struct fuse_forget_link *fuse_alloc_forget(void);
|
2005-09-09 20:10:28 +00:00
|
|
|
|
2012-08-19 12:53:23 +00:00
|
|
|
/* Used by READDIRPLUS */
|
|
|
|
void fuse_force_forget(struct file *file, u64 nodeid);
|
|
|
|
|
2005-09-09 20:10:36 +00:00
|
|
|
/**
|
2006-01-17 06:14:45 +00:00
|
|
|
* Initialize READ or READDIR request
|
2005-09-09 20:10:36 +00:00
|
|
|
*/
|
2007-11-29 00:22:00 +00:00
|
|
|
void fuse_read_fill(struct fuse_req *req, struct file *file,
|
2009-04-28 14:56:37 +00:00
|
|
|
loff_t pos, size_t count, int opcode);
|
2005-09-09 20:10:36 +00:00
|
|
|
|
|
|
|
/**
|
|
|
|
* Send OPEN or OPENDIR request
|
|
|
|
*/
|
2009-04-28 14:56:37 +00:00
|
|
|
int fuse_open_common(struct inode *inode, struct file *file, bool isdir);
|
2005-09-09 20:10:36 +00:00
|
|
|
|
2008-11-26 11:03:55 +00:00
|
|
|
struct fuse_file *fuse_file_alloc(struct fuse_conn *fc);
|
2009-04-28 14:56:37 +00:00
|
|
|
struct fuse_file *fuse_file_get(struct fuse_file *ff);
|
2005-11-07 08:59:51 +00:00
|
|
|
void fuse_file_free(struct fuse_file *ff);
|
2009-04-28 14:56:37 +00:00
|
|
|
void fuse_finish_open(struct inode *inode, struct file *file);
|
2005-11-07 08:59:51 +00:00
|
|
|
|
2009-04-28 14:56:39 +00:00
|
|
|
void fuse_sync_release(struct fuse_file *ff, int flags);
|
2007-10-17 06:31:00 +00:00
|
|
|
|
2005-09-09 20:10:36 +00:00
|
|
|
/**
|
|
|
|
* Send RELEASE or RELEASEDIR request
|
|
|
|
*/
|
2009-04-28 14:56:39 +00:00
|
|
|
void fuse_release_common(struct file *file, int opcode);
|
2005-09-09 20:10:36 +00:00
|
|
|
|
2005-09-09 20:10:38 +00:00
|
|
|
/**
|
|
|
|
* Send FSYNC or FSYNCDIR request
|
|
|
|
*/
|
2011-07-17 00:44:56 +00:00
|
|
|
int fuse_fsync_common(struct file *file, loff_t start, loff_t end,
|
|
|
|
int datasync, int isdir);
|
2005-09-09 20:10:38 +00:00
|
|
|
|
2008-11-26 11:03:55 +00:00
|
|
|
/**
|
|
|
|
* Notify poll wakeup
|
|
|
|
*/
|
|
|
|
int fuse_notify_poll_wakeup(struct fuse_conn *fc,
|
|
|
|
struct fuse_notify_poll_wakeup_out *outarg);
|
|
|
|
|
2005-09-09 20:10:30 +00:00
|
|
|
/**
|
2005-10-30 23:02:51 +00:00
|
|
|
* Initialize file operations on a regular file
|
2005-09-09 20:10:30 +00:00
|
|
|
*/
|
|
|
|
void fuse_init_file_inode(struct inode *inode);
|
|
|
|
|
2005-09-09 20:10:28 +00:00
|
|
|
/**
|
2005-10-30 23:02:51 +00:00
|
|
|
* Initialize inode operations on regular files and special files
|
2005-09-09 20:10:28 +00:00
|
|
|
*/
|
|
|
|
void fuse_init_common(struct inode *inode);
|
|
|
|
|
|
|
|
/**
|
2005-10-30 23:02:51 +00:00
|
|
|
* Initialize inode and file operations on a directory
|
2005-09-09 20:10:28 +00:00
|
|
|
*/
|
|
|
|
void fuse_init_dir(struct inode *inode);
|
|
|
|
|
|
|
|
/**
|
2005-10-30 23:02:51 +00:00
|
|
|
* Initialize inode operations on a symlink
|
2005-09-09 20:10:28 +00:00
|
|
|
*/
|
|
|
|
void fuse_init_symlink(struct inode *inode);
|
|
|
|
|
|
|
|
/**
|
|
|
|
* Change attributes of an inode
|
|
|
|
*/
|
fuse: fix race between getattr and write
Getattr and lookup operations can be running in parallel to attribute changing
operations, such as write and setattr.
This means, that if for example getattr was slower than a write, the cached
size attribute could be set to a stale value.
To prevent this race, introduce a per-filesystem attribute version counter.
This counter is incremented whenever cached attributes are modified, and the
incremented value stored in the inode.
Before storing new attributes in the cache, getattr and lookup check, using
the version number, whether the attributes have been modified during the
request's lifetime. If so, the returned attributes are not cached, because
they might be stale.
Thanks to Jakub Bogusz for the bug report and test program.
[akpm@linux-foundation.org: coding-style fixes]
Signed-off-by: Miklos Szeredi <mszeredi@suse.cz>
Cc: Jakub Bogusz <jakub.bogusz@gemius.pl>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
2007-10-18 10:06:58 +00:00
|
|
|
void fuse_change_attributes(struct inode *inode, struct fuse_attr *attr,
|
|
|
|
u64 attr_valid, u64 attr_version);
|
2005-09-09 20:10:28 +00:00
|
|
|
|
fuse: support writable mmap
Quoting Linus (3 years ago, FUSE inclusion discussions):
"User-space filesystems are hard to get right. I'd claim that they
are almost impossible, unless you limit them somehow (shared
writable mappings are the nastiest part - if you don't have those,
you can reasonably limit your problems by limiting the number of
dirty pages you accept through normal "write()" calls)."
Instead of attempting the impossible, I've just waited for the dirty page
accounting infrastructure to materialize (thanks to Peter Zijlstra and
others). This nicely solved the biggest problem: limiting the number of pages
used for write caching.
Some small details remained, however, which this largish patch attempts to
address. It provides a page writeback implementation for fuse, which is
completely safe against VM related deadlocks. Performance may not be very
good for certain usage patterns, but generally it should be acceptable.
It has been tested extensively with fsx-linux and bash-shared-mapping.
Fuse page writeback design
--------------------------
fuse_writepage() allocates a new temporary page with GFP_NOFS|__GFP_HIGHMEM.
It copies the contents of the original page, and queues a WRITE request to the
userspace filesystem using this temp page.
The writeback is finished instantly from the MM's point of view: the page is
removed from the radix trees, and the PageDirty and PageWriteback flags are
cleared.
For the duration of the actual write, the NR_WRITEBACK_TEMP counter is
incremented. The per-bdi writeback count is not decremented until the actual
write completes.
On dirtying the page, fuse waits for a previous write to finish before
proceeding. This makes sure, there can only be one temporary page used at a
time for one cached page.
This approach is wasteful in both memory and CPU bandwidth, so why is this
complication needed?
The basic problem is that there can be no guarantee about the time in which
the userspace filesystem will complete a write. It may be buggy or even
malicious, and fail to complete WRITE requests. We don't want unrelated parts
of the system to grind to a halt in such cases.
Also a filesystem may need additional resources (particularly memory) to
complete a WRITE request. There's a great danger of a deadlock if that
allocation may wait for the writepage to finish.
Currently there are several cases where the kernel can block on page
writeback:
- allocation order is larger than PAGE_ALLOC_COSTLY_ORDER
- page migration
- throttle_vm_writeout (through NR_WRITEBACK)
- sync(2)
Of course in some cases (fsync, msync) we explicitly want to allow blocking.
So for these cases new code has to be added to fuse, since the VM is not
tracking writeback pages for us any more.
As an extra safetly measure, the maximum dirty ratio allocated to a single
fuse filesystem is set to 1% by default. This way one (or several) buggy or
malicious fuse filesystems cannot slow down the rest of the system by hogging
dirty memory.
With appropriate privileges, this limit can be raised through
'/sys/class/bdi/<bdi>/max_ratio'.
Signed-off-by: Miklos Szeredi <mszeredi@suse.cz>
Cc: Peter Zijlstra <a.p.zijlstra@chello.nl>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
2008-04-30 07:54:41 +00:00
|
|
|
void fuse_change_attributes_common(struct inode *inode, struct fuse_attr *attr,
|
|
|
|
u64 attr_valid);
|
|
|
|
|
2005-09-09 20:10:27 +00:00
|
|
|
/**
|
|
|
|
* Initialize the client device
|
|
|
|
*/
|
|
|
|
int fuse_dev_init(void);
|
|
|
|
|
|
|
|
/**
|
|
|
|
* Cleanup the client device
|
|
|
|
*/
|
|
|
|
void fuse_dev_cleanup(void);
|
|
|
|
|
2006-06-25 12:48:51 +00:00
|
|
|
int fuse_ctl_init(void);
|
|
|
|
void fuse_ctl_cleanup(void);
|
|
|
|
|
2005-09-09 20:10:27 +00:00
|
|
|
/**
|
|
|
|
* Allocate a request
|
|
|
|
*/
|
2012-10-26 15:48:07 +00:00
|
|
|
struct fuse_req *fuse_request_alloc(unsigned npages);
|
2005-09-09 20:10:27 +00:00
|
|
|
|
2012-10-26 15:48:07 +00:00
|
|
|
struct fuse_req *fuse_request_alloc_nofs(unsigned npages);
|
fuse: support writable mmap
Quoting Linus (3 years ago, FUSE inclusion discussions):
"User-space filesystems are hard to get right. I'd claim that they
are almost impossible, unless you limit them somehow (shared
writable mappings are the nastiest part - if you don't have those,
you can reasonably limit your problems by limiting the number of
dirty pages you accept through normal "write()" calls)."
Instead of attempting the impossible, I've just waited for the dirty page
accounting infrastructure to materialize (thanks to Peter Zijlstra and
others). This nicely solved the biggest problem: limiting the number of pages
used for write caching.
Some small details remained, however, which this largish patch attempts to
address. It provides a page writeback implementation for fuse, which is
completely safe against VM related deadlocks. Performance may not be very
good for certain usage patterns, but generally it should be acceptable.
It has been tested extensively with fsx-linux and bash-shared-mapping.
Fuse page writeback design
--------------------------
fuse_writepage() allocates a new temporary page with GFP_NOFS|__GFP_HIGHMEM.
It copies the contents of the original page, and queues a WRITE request to the
userspace filesystem using this temp page.
The writeback is finished instantly from the MM's point of view: the page is
removed from the radix trees, and the PageDirty and PageWriteback flags are
cleared.
For the duration of the actual write, the NR_WRITEBACK_TEMP counter is
incremented. The per-bdi writeback count is not decremented until the actual
write completes.
On dirtying the page, fuse waits for a previous write to finish before
proceeding. This makes sure, there can only be one temporary page used at a
time for one cached page.
This approach is wasteful in both memory and CPU bandwidth, so why is this
complication needed?
The basic problem is that there can be no guarantee about the time in which
the userspace filesystem will complete a write. It may be buggy or even
malicious, and fail to complete WRITE requests. We don't want unrelated parts
of the system to grind to a halt in such cases.
Also a filesystem may need additional resources (particularly memory) to
complete a WRITE request. There's a great danger of a deadlock if that
allocation may wait for the writepage to finish.
Currently there are several cases where the kernel can block on page
writeback:
- allocation order is larger than PAGE_ALLOC_COSTLY_ORDER
- page migration
- throttle_vm_writeout (through NR_WRITEBACK)
- sync(2)
Of course in some cases (fsync, msync) we explicitly want to allow blocking.
So for these cases new code has to be added to fuse, since the VM is not
tracking writeback pages for us any more.
As an extra safetly measure, the maximum dirty ratio allocated to a single
fuse filesystem is set to 1% by default. This way one (or several) buggy or
malicious fuse filesystems cannot slow down the rest of the system by hogging
dirty memory.
With appropriate privileges, this limit can be raised through
'/sys/class/bdi/<bdi>/max_ratio'.
Signed-off-by: Miklos Szeredi <mszeredi@suse.cz>
Cc: Peter Zijlstra <a.p.zijlstra@chello.nl>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
2008-04-30 07:54:41 +00:00
|
|
|
|
2005-09-09 20:10:27 +00:00
|
|
|
/**
|
|
|
|
* Free a request
|
|
|
|
*/
|
|
|
|
void fuse_request_free(struct fuse_req *req);
|
|
|
|
|
|
|
|
/**
|
2012-10-26 15:48:30 +00:00
|
|
|
* Get a request, may fail with -ENOMEM,
|
|
|
|
* caller should specify # elements in req->pages[] explicitly
|
2005-09-09 20:10:27 +00:00
|
|
|
*/
|
2012-10-26 15:48:30 +00:00
|
|
|
struct fuse_req *fuse_get_req(struct fuse_conn *fc, unsigned npages);
|
2013-03-21 14:02:04 +00:00
|
|
|
struct fuse_req *fuse_get_req_for_background(struct fuse_conn *fc,
|
|
|
|
unsigned npages);
|
2012-10-26 15:48:30 +00:00
|
|
|
|
2012-12-14 15:20:51 +00:00
|
|
|
/*
|
|
|
|
* Increment reference count on request
|
|
|
|
*/
|
|
|
|
void __fuse_get_request(struct fuse_req *req);
|
|
|
|
|
2012-10-26 15:48:30 +00:00
|
|
|
/**
|
|
|
|
* Get a request, may fail with -ENOMEM,
|
|
|
|
* useful for callers who doesn't use req->pages[]
|
|
|
|
*/
|
|
|
|
static inline struct fuse_req *fuse_get_req_nopages(struct fuse_conn *fc)
|
|
|
|
{
|
|
|
|
return fuse_get_req(fc, 0);
|
|
|
|
}
|
2005-09-09 20:10:27 +00:00
|
|
|
|
2006-06-25 12:48:52 +00:00
|
|
|
/**
|
|
|
|
* Gets a requests for a file operation, always succeeds
|
|
|
|
*/
|
2012-10-26 15:48:30 +00:00
|
|
|
struct fuse_req *fuse_get_req_nofail_nopages(struct fuse_conn *fc,
|
|
|
|
struct file *file);
|
2006-06-25 12:48:52 +00:00
|
|
|
|
2005-09-09 20:10:27 +00:00
|
|
|
/**
|
2006-04-11 05:54:58 +00:00
|
|
|
* Decrement reference count of a request. If count goes to zero free
|
|
|
|
* the request.
|
2005-09-09 20:10:27 +00:00
|
|
|
*/
|
|
|
|
void fuse_put_request(struct fuse_conn *fc, struct fuse_req *req);
|
|
|
|
|
|
|
|
/**
|
2005-09-09 20:10:39 +00:00
|
|
|
* Send a request (synchronous)
|
2005-09-09 20:10:27 +00:00
|
|
|
*/
|
2008-11-26 11:03:55 +00:00
|
|
|
void fuse_request_send(struct fuse_conn *fc, struct fuse_req *req);
|
2005-09-09 20:10:27 +00:00
|
|
|
|
|
|
|
/**
|
|
|
|
* Send a request in the background
|
|
|
|
*/
|
2008-11-26 11:03:55 +00:00
|
|
|
void fuse_request_send_background(struct fuse_conn *fc, struct fuse_req *req);
|
2005-09-09 20:10:27 +00:00
|
|
|
|
2008-11-26 11:03:55 +00:00
|
|
|
void fuse_request_send_background_locked(struct fuse_conn *fc,
|
|
|
|
struct fuse_req *req);
|
fuse: support writable mmap
Quoting Linus (3 years ago, FUSE inclusion discussions):
"User-space filesystems are hard to get right. I'd claim that they
are almost impossible, unless you limit them somehow (shared
writable mappings are the nastiest part - if you don't have those,
you can reasonably limit your problems by limiting the number of
dirty pages you accept through normal "write()" calls)."
Instead of attempting the impossible, I've just waited for the dirty page
accounting infrastructure to materialize (thanks to Peter Zijlstra and
others). This nicely solved the biggest problem: limiting the number of pages
used for write caching.
Some small details remained, however, which this largish patch attempts to
address. It provides a page writeback implementation for fuse, which is
completely safe against VM related deadlocks. Performance may not be very
good for certain usage patterns, but generally it should be acceptable.
It has been tested extensively with fsx-linux and bash-shared-mapping.
Fuse page writeback design
--------------------------
fuse_writepage() allocates a new temporary page with GFP_NOFS|__GFP_HIGHMEM.
It copies the contents of the original page, and queues a WRITE request to the
userspace filesystem using this temp page.
The writeback is finished instantly from the MM's point of view: the page is
removed from the radix trees, and the PageDirty and PageWriteback flags are
cleared.
For the duration of the actual write, the NR_WRITEBACK_TEMP counter is
incremented. The per-bdi writeback count is not decremented until the actual
write completes.
On dirtying the page, fuse waits for a previous write to finish before
proceeding. This makes sure, there can only be one temporary page used at a
time for one cached page.
This approach is wasteful in both memory and CPU bandwidth, so why is this
complication needed?
The basic problem is that there can be no guarantee about the time in which
the userspace filesystem will complete a write. It may be buggy or even
malicious, and fail to complete WRITE requests. We don't want unrelated parts
of the system to grind to a halt in such cases.
Also a filesystem may need additional resources (particularly memory) to
complete a WRITE request. There's a great danger of a deadlock if that
allocation may wait for the writepage to finish.
Currently there are several cases where the kernel can block on page
writeback:
- allocation order is larger than PAGE_ALLOC_COSTLY_ORDER
- page migration
- throttle_vm_writeout (through NR_WRITEBACK)
- sync(2)
Of course in some cases (fsync, msync) we explicitly want to allow blocking.
So for these cases new code has to be added to fuse, since the VM is not
tracking writeback pages for us any more.
As an extra safetly measure, the maximum dirty ratio allocated to a single
fuse filesystem is set to 1% by default. This way one (or several) buggy or
malicious fuse filesystems cannot slow down the rest of the system by hogging
dirty memory.
With appropriate privileges, this limit can be raised through
'/sys/class/bdi/<bdi>/max_ratio'.
Signed-off-by: Miklos Szeredi <mszeredi@suse.cz>
Cc: Peter Zijlstra <a.p.zijlstra@chello.nl>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
2008-04-30 07:54:41 +00:00
|
|
|
|
2006-04-26 08:48:55 +00:00
|
|
|
/* Abort all requests */
|
2006-01-17 06:14:41 +00:00
|
|
|
void fuse_abort_conn(struct fuse_conn *fc);
|
|
|
|
|
2005-09-09 20:10:28 +00:00
|
|
|
/**
|
|
|
|
* Invalidate inode attributes
|
|
|
|
*/
|
|
|
|
void fuse_invalidate_attr(struct inode *inode);
|
2006-06-25 12:48:51 +00:00
|
|
|
|
2008-07-25 08:49:00 +00:00
|
|
|
void fuse_invalidate_entry_cache(struct dentry *entry);
|
|
|
|
|
2006-06-25 12:48:51 +00:00
|
|
|
/**
|
|
|
|
* Acquire reference to fuse_conn
|
|
|
|
*/
|
|
|
|
struct fuse_conn *fuse_conn_get(struct fuse_conn *fc);
|
|
|
|
|
2009-04-14 01:54:53 +00:00
|
|
|
void fuse_conn_kill(struct fuse_conn *fc);
|
|
|
|
|
2008-11-26 11:03:55 +00:00
|
|
|
/**
|
|
|
|
* Initialize fuse_conn
|
|
|
|
*/
|
2009-04-14 01:54:52 +00:00
|
|
|
void fuse_conn_init(struct fuse_conn *fc);
|
2008-11-26 11:03:55 +00:00
|
|
|
|
2006-06-25 12:48:51 +00:00
|
|
|
/**
|
|
|
|
* Release reference to fuse_conn
|
|
|
|
*/
|
|
|
|
void fuse_conn_put(struct fuse_conn *fc);
|
|
|
|
|
|
|
|
/**
|
|
|
|
* Add connection to control filesystem
|
|
|
|
*/
|
|
|
|
int fuse_ctl_add_conn(struct fuse_conn *fc);
|
|
|
|
|
|
|
|
/**
|
|
|
|
* Remove connection from control filesystem
|
|
|
|
*/
|
|
|
|
void fuse_ctl_remove_conn(struct fuse_conn *fc);
|
2007-04-08 23:04:00 +00:00
|
|
|
|
|
|
|
/**
|
|
|
|
* Is file type valid?
|
|
|
|
*/
|
|
|
|
int fuse_valid_type(int m);
|
2007-10-18 10:06:58 +00:00
|
|
|
|
|
|
|
/**
|
2013-01-15 06:30:00 +00:00
|
|
|
* Is current process allowed to perform filesystem operation?
|
2007-10-18 10:06:58 +00:00
|
|
|
*/
|
2013-01-15 06:30:00 +00:00
|
|
|
int fuse_allow_current_process(struct fuse_conn *fc);
|
2007-10-18 10:07:04 +00:00
|
|
|
|
|
|
|
u64 fuse_lock_owner_id(struct fuse_conn *fc, fl_owner_t id);
|
2007-11-29 00:21:59 +00:00
|
|
|
|
|
|
|
int fuse_update_attributes(struct inode *inode, struct kstat *stat,
|
|
|
|
struct file *file, bool *refreshed);
|
fuse: support writable mmap
Quoting Linus (3 years ago, FUSE inclusion discussions):
"User-space filesystems are hard to get right. I'd claim that they
are almost impossible, unless you limit them somehow (shared
writable mappings are the nastiest part - if you don't have those,
you can reasonably limit your problems by limiting the number of
dirty pages you accept through normal "write()" calls)."
Instead of attempting the impossible, I've just waited for the dirty page
accounting infrastructure to materialize (thanks to Peter Zijlstra and
others). This nicely solved the biggest problem: limiting the number of pages
used for write caching.
Some small details remained, however, which this largish patch attempts to
address. It provides a page writeback implementation for fuse, which is
completely safe against VM related deadlocks. Performance may not be very
good for certain usage patterns, but generally it should be acceptable.
It has been tested extensively with fsx-linux and bash-shared-mapping.
Fuse page writeback design
--------------------------
fuse_writepage() allocates a new temporary page with GFP_NOFS|__GFP_HIGHMEM.
It copies the contents of the original page, and queues a WRITE request to the
userspace filesystem using this temp page.
The writeback is finished instantly from the MM's point of view: the page is
removed from the radix trees, and the PageDirty and PageWriteback flags are
cleared.
For the duration of the actual write, the NR_WRITEBACK_TEMP counter is
incremented. The per-bdi writeback count is not decremented until the actual
write completes.
On dirtying the page, fuse waits for a previous write to finish before
proceeding. This makes sure, there can only be one temporary page used at a
time for one cached page.
This approach is wasteful in both memory and CPU bandwidth, so why is this
complication needed?
The basic problem is that there can be no guarantee about the time in which
the userspace filesystem will complete a write. It may be buggy or even
malicious, and fail to complete WRITE requests. We don't want unrelated parts
of the system to grind to a halt in such cases.
Also a filesystem may need additional resources (particularly memory) to
complete a WRITE request. There's a great danger of a deadlock if that
allocation may wait for the writepage to finish.
Currently there are several cases where the kernel can block on page
writeback:
- allocation order is larger than PAGE_ALLOC_COSTLY_ORDER
- page migration
- throttle_vm_writeout (through NR_WRITEBACK)
- sync(2)
Of course in some cases (fsync, msync) we explicitly want to allow blocking.
So for these cases new code has to be added to fuse, since the VM is not
tracking writeback pages for us any more.
As an extra safetly measure, the maximum dirty ratio allocated to a single
fuse filesystem is set to 1% by default. This way one (or several) buggy or
malicious fuse filesystems cannot slow down the rest of the system by hogging
dirty memory.
With appropriate privileges, this limit can be raised through
'/sys/class/bdi/<bdi>/max_ratio'.
Signed-off-by: Miklos Szeredi <mszeredi@suse.cz>
Cc: Peter Zijlstra <a.p.zijlstra@chello.nl>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
2008-04-30 07:54:41 +00:00
|
|
|
|
|
|
|
void fuse_flush_writepages(struct inode *inode);
|
|
|
|
|
|
|
|
void fuse_set_nowrite(struct inode *inode);
|
|
|
|
void fuse_release_nowrite(struct inode *inode);
|
2008-04-30 07:54:43 +00:00
|
|
|
|
|
|
|
u64 fuse_get_attr_version(struct fuse_conn *fc);
|
2008-10-16 14:08:57 +00:00
|
|
|
|
2009-05-31 15:13:57 +00:00
|
|
|
/**
|
|
|
|
* File-system tells the kernel to invalidate cache for the given node id.
|
|
|
|
*/
|
|
|
|
int fuse_reverse_inval_inode(struct super_block *sb, u64 nodeid,
|
|
|
|
loff_t offset, loff_t len);
|
|
|
|
|
|
|
|
/**
|
|
|
|
* File-system tells the kernel to invalidate parent attributes and
|
|
|
|
* the dentry matching parent/name.
|
2011-12-06 20:50:06 +00:00
|
|
|
*
|
|
|
|
* If the child_nodeid is non-zero and:
|
|
|
|
* - matches the inode number for the dentry matching parent/name,
|
|
|
|
* - is not a mount point
|
|
|
|
* - is a file or oan empty directory
|
|
|
|
* then the dentry is unhashed (d_delete()).
|
2009-05-31 15:13:57 +00:00
|
|
|
*/
|
|
|
|
int fuse_reverse_inval_entry(struct super_block *sb, u64 parent_nodeid,
|
2011-12-06 20:50:06 +00:00
|
|
|
u64 child_nodeid, struct qstr *name);
|
2009-05-31 15:13:57 +00:00
|
|
|
|
2009-04-14 01:54:53 +00:00
|
|
|
int fuse_do_open(struct fuse_conn *fc, u64 nodeid, struct file *file,
|
|
|
|
bool isdir);
|
2012-12-14 15:20:51 +00:00
|
|
|
ssize_t fuse_direct_io(struct fuse_io_priv *io, const struct iovec *iov,
|
2012-11-10 15:55:56 +00:00
|
|
|
unsigned long nr_segs, size_t count, loff_t *ppos,
|
|
|
|
int write);
|
2009-04-14 01:54:53 +00:00
|
|
|
long fuse_do_ioctl(struct file *file, unsigned int cmd, unsigned long arg,
|
|
|
|
unsigned int flags);
|
2011-12-13 10:58:49 +00:00
|
|
|
long fuse_ioctl_common(struct file *file, unsigned int cmd,
|
|
|
|
unsigned long arg, unsigned int flags);
|
2009-04-14 01:54:53 +00:00
|
|
|
unsigned fuse_file_poll(struct file *file, poll_table *wait);
|
|
|
|
int fuse_dev_release(struct inode *inode, struct file *file);
|
|
|
|
|
2010-07-12 12:41:40 +00:00
|
|
|
void fuse_write_update_size(struct inode *inode, loff_t pos);
|
|
|
|
|
2012-12-18 10:05:08 +00:00
|
|
|
int fuse_do_setattr(struct inode *inode, struct iattr *attr,
|
|
|
|
struct file *file);
|
|
|
|
|
2008-10-16 14:08:57 +00:00
|
|
|
#endif /* _FS_FUSE_I_H */
|