[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 22:10:26 +02:00
|
|
|
/*
|
|
|
|
FUSE: Filesystem in Userspace
|
2006-04-11 07:54:55 +02:00
|
|
|
Copyright (C) 2001-2006 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 22:10:26 +02:00
|
|
|
|
|
|
|
This program can be distributed under the terms of the GNU GPL.
|
|
|
|
See the file COPYING.
|
|
|
|
*/
|
|
|
|
|
|
|
|
#include <linux/fuse.h>
|
|
|
|
#include <linux/fs.h>
|
2006-06-25 14:48:50 +02: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 22:10:26 +02: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 14:48:51 +02:00
|
|
|
#include <linux/mutex.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 22:10:26 +02:00
|
|
|
|
2005-09-09 22:10:27 +02:00
|
|
|
/** Max number of pages that can be used in a single read request */
|
|
|
|
#define FUSE_MAX_PAGES_PER_REQ 32
|
|
|
|
|
2006-04-11 07:54:59 +02:00
|
|
|
/** Maximum number of outstanding background requests */
|
2007-10-17 08:30:59 +02:00
|
|
|
#define FUSE_MAX_BACKGROUND 12
|
|
|
|
|
|
|
|
/** Congestion starts at 75% of maximum */
|
|
|
|
#define FUSE_CONGESTION_THRESHOLD (FUSE_MAX_BACKGROUND * 75 / 100)
|
2006-04-11 07:54:59 +02:00
|
|
|
|
2006-01-06 09:19:40 +01:00
|
|
|
/** It could be as large as PATH_MAX, but would that have any uses? */
|
|
|
|
#define FUSE_NAME_MAX 1024
|
|
|
|
|
2006-06-25 14:48:51 +02:00
|
|
|
/** Number of dentries for each connection in the control filesystem */
|
|
|
|
#define FUSE_CTL_NUM_DENTRIES 3
|
|
|
|
|
2005-09-09 22:10:31 +02: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)
|
|
|
|
|
2006-06-25 14:48:51 +02: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 22:10:35 +02: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 22:10:26 +02: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 22:10:29 +02:00
|
|
|
/** Number of lookups on this inode */
|
|
|
|
u64 nlookup;
|
|
|
|
|
2005-09-09 22:10:28 +02:00
|
|
|
/** The request used for sending the FORGET message */
|
|
|
|
struct fuse_req *forget_req;
|
|
|
|
|
[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 22:10:26 +02:00
|
|
|
/** Time in jiffies until the file attributes are valid */
|
2006-07-30 12:04:10 +02:00
|
|
|
u64 i_time;
|
2007-10-17 08:31:03 +02:00
|
|
|
|
|
|
|
/** The sticky bit in inode->i_mode may have been removed, so
|
|
|
|
preserve the original mode */
|
|
|
|
mode_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 12:06:58 +02:00
|
|
|
|
|
|
|
/** Version of last attribute change */
|
|
|
|
u64 attr_version;
|
2007-10-18 12:07:03 +02:00
|
|
|
|
|
|
|
/** Files usable in writepage. Protected by fc->lock */
|
|
|
|
struct list_head write_files;
|
[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 22:10:26 +02:00
|
|
|
};
|
|
|
|
|
2005-09-09 22:10:30 +02:00
|
|
|
/** FUSE specific file data */
|
|
|
|
struct fuse_file {
|
|
|
|
/** Request reserved for flush and release */
|
2006-06-25 14:48:52 +02:00
|
|
|
struct fuse_req *reserved_req;
|
2005-09-09 22:10:30 +02:00
|
|
|
|
|
|
|
/** File handle used by userspace */
|
|
|
|
u64 fh;
|
2007-10-17 08:31:00 +02:00
|
|
|
|
|
|
|
/** Refcount */
|
|
|
|
atomic_t count;
|
2007-10-18 12:07:03 +02:00
|
|
|
|
|
|
|
/** Entry on inode's write_files list */
|
|
|
|
struct list_head write_entry;
|
2005-09-09 22:10:30 +02:00
|
|
|
};
|
|
|
|
|
2005-09-09 22:10:27 +02: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 07:14:52 +01:00
|
|
|
/*
|
|
|
|
* The following bitfields are not changed during the request
|
|
|
|
* processing
|
|
|
|
*/
|
|
|
|
|
2005-09-09 22:10:27 +02: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;
|
|
|
|
|
|
|
|
/** Number or arguments */
|
|
|
|
unsigned numargs;
|
|
|
|
|
|
|
|
/** Array of arguments */
|
|
|
|
struct fuse_arg args[3];
|
|
|
|
};
|
|
|
|
|
2006-01-17 07:14:31 +01:00
|
|
|
/** The request state */
|
|
|
|
enum fuse_req_state {
|
|
|
|
FUSE_REQ_INIT = 0,
|
|
|
|
FUSE_REQ_PENDING,
|
|
|
|
FUSE_REQ_READING,
|
|
|
|
FUSE_REQ_SENT,
|
2006-06-25 14:48:54 +02:00
|
|
|
FUSE_REQ_WRITING,
|
2006-01-17 07:14:31 +01:00
|
|
|
FUSE_REQ_FINISHED
|
|
|
|
};
|
|
|
|
|
2006-01-17 07:14:42 +01:00
|
|
|
struct fuse_conn;
|
|
|
|
|
2005-09-09 22:10:27 +02:00
|
|
|
/**
|
|
|
|
* A request to the client
|
|
|
|
*/
|
|
|
|
struct fuse_req {
|
2006-04-11 07:54:58 +02:00
|
|
|
/** This can be on either pending processing or io lists in
|
|
|
|
fuse_conn */
|
2005-09-09 22:10:27 +02:00
|
|
|
struct list_head list;
|
|
|
|
|
2006-06-25 14:48:54 +02:00
|
|
|
/** Entry on the interrupts list */
|
|
|
|
struct list_head intr_entry;
|
|
|
|
|
2005-09-09 22:10:27 +02:00
|
|
|
/** refcount */
|
|
|
|
atomic_t count;
|
|
|
|
|
2006-06-25 14:48:54 +02:00
|
|
|
/** Unique ID for the interrupt request */
|
|
|
|
u64 intr_unique;
|
|
|
|
|
2006-01-17 07:14:52 +01:00
|
|
|
/*
|
|
|
|
* The following bitfields are either set once before the
|
|
|
|
* request is queued or setting/clearing them is protected by
|
2006-04-11 07:54:55 +02:00
|
|
|
* fuse_conn->lock
|
2006-01-17 07:14:52 +01:00
|
|
|
*/
|
|
|
|
|
2005-09-09 22:10:27 +02:00
|
|
|
/** True if the request has reply */
|
|
|
|
unsigned isreply:1;
|
|
|
|
|
2006-06-25 14:48:50 +02:00
|
|
|
/** Force sending of the request even if interrupted */
|
|
|
|
unsigned force:1;
|
|
|
|
|
2006-06-25 14:48:53 +02:00
|
|
|
/** The request was aborted */
|
|
|
|
unsigned aborted:1;
|
2005-09-09 22:10:27 +02:00
|
|
|
|
|
|
|
/** Request is sent in the background */
|
|
|
|
unsigned background:1;
|
|
|
|
|
2006-06-25 14:48:54 +02:00
|
|
|
/** The request has been interrupted */
|
|
|
|
unsigned interrupted:1;
|
|
|
|
|
2005-09-09 22:10:27 +02:00
|
|
|
/** Data is being copied to/from the request */
|
|
|
|
unsigned locked:1;
|
|
|
|
|
2006-04-11 21:16:09 +02:00
|
|
|
/** Request is counted as "waiting" */
|
|
|
|
unsigned waiting:1;
|
|
|
|
|
2006-01-17 07:14:31 +01:00
|
|
|
/** State of the request */
|
|
|
|
enum fuse_req_state state;
|
2005-09-09 22:10:27 +02: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 {
|
2005-09-09 22:10:28 +02:00
|
|
|
struct fuse_forget_in forget_in;
|
2005-09-09 22:10:30 +02:00
|
|
|
struct fuse_release_in release_in;
|
2006-01-06 09:19:41 +01:00
|
|
|
struct fuse_init_in init_in;
|
|
|
|
struct fuse_init_out init_out;
|
2006-01-17 07:14:45 +01:00
|
|
|
struct fuse_read_in read_in;
|
2007-10-18 12:07:03 +02:00
|
|
|
struct {
|
|
|
|
struct fuse_write_in in;
|
|
|
|
struct fuse_write_out out;
|
|
|
|
} write;
|
2006-06-25 14:48:52 +02:00
|
|
|
struct fuse_lk_in lk_in;
|
2005-09-09 22:10:27 +02:00
|
|
|
} misc;
|
|
|
|
|
|
|
|
/** page vector */
|
|
|
|
struct page *pages[FUSE_MAX_PAGES_PER_REQ];
|
|
|
|
|
|
|
|
/** number of pages in vector */
|
|
|
|
unsigned num_pages;
|
|
|
|
|
|
|
|
/** offset of data on first page */
|
|
|
|
unsigned page_offset;
|
|
|
|
|
|
|
|
/** File used in the request (or NULL) */
|
2007-10-17 08:31:00 +02:00
|
|
|
struct fuse_file *ff;
|
2006-01-17 07:14:42 +01:00
|
|
|
|
2006-06-25 14:48:50 +02:00
|
|
|
/** vfsmount used in release */
|
|
|
|
struct vfsmount *vfsmount;
|
|
|
|
|
|
|
|
/** dentry used in release */
|
|
|
|
struct dentry *dentry;
|
|
|
|
|
2006-01-17 07:14:42 +01:00
|
|
|
/** Request completion callback */
|
|
|
|
void (*end)(struct fuse_conn *, struct fuse_req *);
|
2006-06-25 14:48:52 +02:00
|
|
|
|
|
|
|
/** Request is stolen from fuse_file->reserved_req */
|
|
|
|
struct file *stolen_file;
|
2005-09-09 22:10:27 +02: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 22:10:26 +02: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 07:54:55 +02:00
|
|
|
/** Lock protecting accessess to members of this structure */
|
|
|
|
spinlock_t lock;
|
|
|
|
|
2006-10-17 09:10:11 +02:00
|
|
|
/** Mutex protecting against directory alias creation */
|
|
|
|
struct mutex inst_mutex;
|
|
|
|
|
2006-06-25 14:48:51 +02:00
|
|
|
/** Refcount */
|
|
|
|
atomic_t count;
|
|
|
|
|
[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 22:10:26 +02:00
|
|
|
/** The user id for this mount */
|
|
|
|
uid_t user_id;
|
|
|
|
|
2005-09-09 22:10:34 +02:00
|
|
|
/** The group id for this mount */
|
|
|
|
gid_t group_id;
|
|
|
|
|
2005-09-09 22:10:31 +02:00
|
|
|
/** The fuse mount flags for this mount */
|
|
|
|
unsigned flags;
|
|
|
|
|
2005-09-09 22:10:33 +02:00
|
|
|
/** Maximum read size */
|
|
|
|
unsigned max_read;
|
|
|
|
|
2005-09-09 22:10:35 +02:00
|
|
|
/** Maximum write size */
|
|
|
|
unsigned max_write;
|
|
|
|
|
2005-09-09 22:10:27 +02: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 07:14:31 +01:00
|
|
|
/** The list of requests under I/O */
|
|
|
|
struct list_head io;
|
|
|
|
|
2006-04-11 07:54:59 +02:00
|
|
|
/** Number of requests currently in the background */
|
|
|
|
unsigned num_background;
|
|
|
|
|
2006-06-25 14:48:54 +02:00
|
|
|
/** Pending interrupts */
|
|
|
|
struct list_head interrupts;
|
|
|
|
|
2006-04-11 07:54:59 +02: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 08:31:00 +02:00
|
|
|
|
|
|
|
/** waitq for reserved requests */
|
|
|
|
wait_queue_head_t reserved_req_waitq;
|
2006-04-11 07:54:59 +02:00
|
|
|
|
2005-09-09 22:10:27 +02:00
|
|
|
/** The next unique request id */
|
|
|
|
u64 reqctr;
|
|
|
|
|
2006-01-17 07:14:41 +01:00
|
|
|
/** Connection established, cleared on umount, connection
|
|
|
|
abort and device release */
|
2006-01-17 07:14:52 +01:00
|
|
|
unsigned connected;
|
2005-09-09 22:10:31 +02:00
|
|
|
|
2006-01-17 07:14:52 +01: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 */
|
2005-09-09 22:10:27 +02:00
|
|
|
unsigned conn_error : 1;
|
|
|
|
|
2006-12-07 05:35:52 +01:00
|
|
|
/** Connection successful. Only set in INIT */
|
|
|
|
unsigned conn_init : 1;
|
|
|
|
|
2006-02-01 12:04:40 +01:00
|
|
|
/** Do readpages asynchronously? Only set in INIT */
|
|
|
|
unsigned async_read : 1;
|
|
|
|
|
2007-10-18 12:07:02 +02:00
|
|
|
/** Do not send separate SETATTR request before open(O_TRUNC) */
|
|
|
|
unsigned atomic_o_trunc : 1;
|
|
|
|
|
2006-01-17 07:14:52 +01:00
|
|
|
/*
|
|
|
|
* The following bitfields are only for optimization purposes
|
|
|
|
* and hence races in setting them will not cause malfunction
|
|
|
|
*/
|
|
|
|
|
2005-09-09 22:10:30 +02:00
|
|
|
/** Is fsync not implemented by fs? */
|
|
|
|
unsigned no_fsync : 1;
|
|
|
|
|
2005-09-09 22:10:38 +02:00
|
|
|
/** Is fsyncdir not implemented by fs? */
|
|
|
|
unsigned no_fsyncdir : 1;
|
|
|
|
|
2005-09-09 22:10:30 +02:00
|
|
|
/** Is flush not implemented by fs? */
|
|
|
|
unsigned no_flush : 1;
|
|
|
|
|
2005-09-09 22:10:31 +02:00
|
|
|
/** Is setxattr not implemented by fs? */
|
|
|
|
unsigned no_setxattr : 1;
|
|
|
|
|
|
|
|
/** Is getxattr not implemented by fs? */
|
|
|
|
unsigned no_getxattr : 1;
|
|
|
|
|
|
|
|
/** Is listxattr not implemented by fs? */
|
|
|
|
unsigned no_listxattr : 1;
|
|
|
|
|
|
|
|
/** Is removexattr not implemented by fs? */
|
|
|
|
unsigned no_removexattr : 1;
|
|
|
|
|
2006-06-25 14:48:52 +02:00
|
|
|
/** Are file locking primitives not implemented by fs? */
|
|
|
|
unsigned no_lock : 1;
|
|
|
|
|
2005-11-07 09:59:50 +01:00
|
|
|
/** Is access not implemented by fs? */
|
|
|
|
unsigned no_access : 1;
|
|
|
|
|
2005-11-07 09:59:51 +01:00
|
|
|
/** Is create not implemented by fs? */
|
|
|
|
unsigned no_create : 1;
|
|
|
|
|
2006-06-25 14:48:54 +02:00
|
|
|
/** Is interrupt not implemented by fs? */
|
|
|
|
unsigned no_interrupt : 1;
|
|
|
|
|
2006-12-07 05:35:51 +01:00
|
|
|
/** Is bmap not implemented by fs? */
|
|
|
|
unsigned no_bmap : 1;
|
|
|
|
|
2006-01-17 07:14:38 +01:00
|
|
|
/** The number of requests waiting for completion */
|
|
|
|
atomic_t num_waiting;
|
|
|
|
|
2006-01-06 09:19:36 +01: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 22:10:26 +02:00
|
|
|
/** Backing dev info */
|
|
|
|
struct backing_dev_info bdi;
|
2006-01-17 07:14:35 +01:00
|
|
|
|
2006-06-25 14:48:51 +02:00
|
|
|
/** Entry on the fuse_conn_list */
|
|
|
|
struct list_head entry;
|
|
|
|
|
|
|
|
/** Unique ID */
|
|
|
|
u64 id;
|
|
|
|
|
|
|
|
/** 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 07:54:52 +02:00
|
|
|
|
|
|
|
/** O_ASYNC requests */
|
|
|
|
struct fasync_struct *fasync;
|
2006-06-25 14:48:55 +02:00
|
|
|
|
|
|
|
/** Key for lock owner ID scrambling */
|
|
|
|
u32 scramble_key[4];
|
2006-12-07 05:35:52 +01: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 12:06:58 +02:00
|
|
|
|
|
|
|
/** Version counter for attribute changes */
|
|
|
|
u64 attr_version;
|
[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 22:10:26 +02:00
|
|
|
};
|
|
|
|
|
|
|
|
static inline struct fuse_conn *get_fuse_conn_super(struct super_block *sb)
|
|
|
|
{
|
2006-01-17 07:14:29 +01: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 22:10:26 +02: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 22:10:27 +02:00
|
|
|
/** Device operations */
|
2006-03-28 11:56:42 +02:00
|
|
|
extern const struct file_operations fuse_dev_operations;
|
2005-09-09 22:10:27 +02:00
|
|
|
|
2005-09-09 22:10:28 +02:00
|
|
|
/**
|
|
|
|
* Get a filled in inode
|
|
|
|
*/
|
|
|
|
struct inode *fuse_iget(struct super_block *sb, unsigned long 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 12:06:58 +02:00
|
|
|
int generation, struct fuse_attr *attr,
|
|
|
|
u64 attr_valid, u64 attr_version);
|
2005-09-09 22:10:28 +02:00
|
|
|
|
|
|
|
/**
|
|
|
|
* Send FORGET command
|
|
|
|
*/
|
|
|
|
void fuse_send_forget(struct fuse_conn *fc, struct fuse_req *req,
|
2005-09-09 22:10:29 +02:00
|
|
|
unsigned long nodeid, u64 nlookup);
|
2005-09-09 22:10:28 +02:00
|
|
|
|
2005-09-09 22:10:36 +02:00
|
|
|
/**
|
2006-01-17 07:14:45 +01:00
|
|
|
* Initialize READ or READDIR request
|
2005-09-09 22:10:36 +02:00
|
|
|
*/
|
2007-11-29 01:22:00 +01:00
|
|
|
void fuse_read_fill(struct fuse_req *req, struct file *file,
|
2006-01-17 07:14:45 +01:00
|
|
|
struct inode *inode, loff_t pos, size_t count, int opcode);
|
2005-09-09 22:10:36 +02:00
|
|
|
|
|
|
|
/**
|
|
|
|
* Send OPEN or OPENDIR request
|
|
|
|
*/
|
|
|
|
int fuse_open_common(struct inode *inode, struct file *file, int isdir);
|
|
|
|
|
2005-11-07 09:59:51 +01:00
|
|
|
struct fuse_file *fuse_file_alloc(void);
|
|
|
|
void fuse_file_free(struct fuse_file *ff);
|
|
|
|
void fuse_finish_open(struct inode *inode, struct file *file,
|
|
|
|
struct fuse_file *ff, struct fuse_open_out *outarg);
|
|
|
|
|
2007-10-17 08:31:00 +02:00
|
|
|
/** Fill in ff->reserved_req with a RELEASE request */
|
|
|
|
void fuse_release_fill(struct fuse_file *ff, u64 nodeid, int flags, int opcode);
|
|
|
|
|
2005-09-09 22:10:36 +02:00
|
|
|
/**
|
|
|
|
* Send RELEASE or RELEASEDIR request
|
|
|
|
*/
|
|
|
|
int fuse_release_common(struct inode *inode, struct file *file, int isdir);
|
|
|
|
|
2005-09-09 22:10:38 +02:00
|
|
|
/**
|
|
|
|
* Send FSYNC or FSYNCDIR request
|
|
|
|
*/
|
|
|
|
int fuse_fsync_common(struct file *file, struct dentry *de, int datasync,
|
|
|
|
int isdir);
|
|
|
|
|
2005-09-09 22:10:30 +02:00
|
|
|
/**
|
2005-10-31 00:02:51 +01:00
|
|
|
* Initialize file operations on a regular file
|
2005-09-09 22:10:30 +02:00
|
|
|
*/
|
|
|
|
void fuse_init_file_inode(struct inode *inode);
|
|
|
|
|
2005-09-09 22:10:28 +02:00
|
|
|
/**
|
2005-10-31 00:02:51 +01:00
|
|
|
* Initialize inode operations on regular files and special files
|
2005-09-09 22:10:28 +02:00
|
|
|
*/
|
|
|
|
void fuse_init_common(struct inode *inode);
|
|
|
|
|
|
|
|
/**
|
2005-10-31 00:02:51 +01:00
|
|
|
* Initialize inode and file operations on a directory
|
2005-09-09 22:10:28 +02:00
|
|
|
*/
|
|
|
|
void fuse_init_dir(struct inode *inode);
|
|
|
|
|
|
|
|
/**
|
2005-10-31 00:02:51 +01:00
|
|
|
* Initialize inode operations on a symlink
|
2005-09-09 22:10:28 +02: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 12:06:58 +02:00
|
|
|
void fuse_change_attributes(struct inode *inode, struct fuse_attr *attr,
|
|
|
|
u64 attr_valid, u64 attr_version);
|
2005-09-09 22:10:28 +02:00
|
|
|
|
2005-09-09 22:10:27 +02:00
|
|
|
/**
|
|
|
|
* Initialize the client device
|
|
|
|
*/
|
|
|
|
int fuse_dev_init(void);
|
|
|
|
|
|
|
|
/**
|
|
|
|
* Cleanup the client device
|
|
|
|
*/
|
|
|
|
void fuse_dev_cleanup(void);
|
|
|
|
|
2006-06-25 14:48:51 +02:00
|
|
|
int fuse_ctl_init(void);
|
|
|
|
void fuse_ctl_cleanup(void);
|
|
|
|
|
2005-09-09 22:10:27 +02:00
|
|
|
/**
|
|
|
|
* Allocate a request
|
|
|
|
*/
|
|
|
|
struct fuse_req *fuse_request_alloc(void);
|
|
|
|
|
|
|
|
/**
|
|
|
|
* Free a request
|
|
|
|
*/
|
|
|
|
void fuse_request_free(struct fuse_req *req);
|
|
|
|
|
|
|
|
/**
|
2006-06-25 14:48:52 +02:00
|
|
|
* Get a request, may fail with -ENOMEM
|
2005-09-09 22:10:27 +02:00
|
|
|
*/
|
2006-04-11 07:54:58 +02:00
|
|
|
struct fuse_req *fuse_get_req(struct fuse_conn *fc);
|
2005-09-09 22:10:27 +02:00
|
|
|
|
2006-06-25 14:48:52 +02:00
|
|
|
/**
|
|
|
|
* Gets a requests for a file operation, always succeeds
|
|
|
|
*/
|
|
|
|
struct fuse_req *fuse_get_req_nofail(struct fuse_conn *fc, struct file *file);
|
|
|
|
|
2005-09-09 22:10:27 +02:00
|
|
|
/**
|
2006-04-11 07:54:58 +02:00
|
|
|
* Decrement reference count of a request. If count goes to zero free
|
|
|
|
* the request.
|
2005-09-09 22:10:27 +02:00
|
|
|
*/
|
|
|
|
void fuse_put_request(struct fuse_conn *fc, struct fuse_req *req);
|
|
|
|
|
|
|
|
/**
|
2005-09-09 22:10:39 +02:00
|
|
|
* Send a request (synchronous)
|
2005-09-09 22:10:27 +02:00
|
|
|
*/
|
|
|
|
void request_send(struct fuse_conn *fc, struct fuse_req *req);
|
|
|
|
|
|
|
|
/**
|
|
|
|
* Send a request with no reply
|
|
|
|
*/
|
|
|
|
void request_send_noreply(struct fuse_conn *fc, struct fuse_req *req);
|
|
|
|
|
|
|
|
/**
|
|
|
|
* Send a request in the background
|
|
|
|
*/
|
|
|
|
void request_send_background(struct fuse_conn *fc, struct fuse_req *req);
|
|
|
|
|
2006-04-26 10:48:55 +02:00
|
|
|
/* Abort all requests */
|
2006-01-17 07:14:41 +01:00
|
|
|
void fuse_abort_conn(struct fuse_conn *fc);
|
|
|
|
|
2005-09-09 22:10:28 +02:00
|
|
|
/**
|
|
|
|
* Invalidate inode attributes
|
|
|
|
*/
|
|
|
|
void fuse_invalidate_attr(struct inode *inode);
|
2006-06-25 14:48:51 +02:00
|
|
|
|
|
|
|
/**
|
|
|
|
* Acquire reference to fuse_conn
|
|
|
|
*/
|
|
|
|
struct fuse_conn *fuse_conn_get(struct fuse_conn *fc);
|
|
|
|
|
|
|
|
/**
|
|
|
|
* 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-09 01:04:00 +02:00
|
|
|
|
|
|
|
/**
|
|
|
|
* Is file type valid?
|
|
|
|
*/
|
|
|
|
int fuse_valid_type(int m);
|
2007-10-18 12:06:58 +02:00
|
|
|
|
|
|
|
/**
|
|
|
|
* Is task allowed to perform filesystem operation?
|
|
|
|
*/
|
|
|
|
int fuse_allow_task(struct fuse_conn *fc, struct task_struct *task);
|
2007-10-18 12:07:04 +02:00
|
|
|
|
|
|
|
u64 fuse_lock_owner_id(struct fuse_conn *fc, fl_owner_t id);
|
2007-11-29 01:21:59 +01:00
|
|
|
|
|
|
|
int fuse_update_attributes(struct inode *inode, struct kstat *stat,
|
|
|
|
struct file *file, bool *refreshed);
|