[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-10 04:10:26 +08:00
|
|
|
/*
|
|
|
|
|
FUSE: Filesystem in Userspace
|
2006-04-11 13:54:55 +08: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-10 04:10:26 +08:00
|
|
|
|
|
|
|
|
This program can be distributed under the terms of the GNU GPL.
|
|
|
|
|
See the file COPYING.
|
|
|
|
|
*/
|
|
|
|
|
|
|
|
|
|
#include "fuse_i.h"
|
|
|
|
|
|
|
|
|
|
#include <linux/pagemap.h>
|
|
|
|
|
#include <linux/slab.h>
|
|
|
|
|
#include <linux/file.h>
|
|
|
|
|
#include <linux/mount.h>
|
|
|
|
|
#include <linux/seq_file.h>
|
|
|
|
|
#include <linux/init.h>
|
|
|
|
|
#include <linux/module.h>
|
|
|
|
|
#include <linux/parser.h>
|
|
|
|
|
#include <linux/statfs.h>
|
|
|
|
|
|
|
|
|
|
MODULE_AUTHOR("Miklos Szeredi <miklos@szeredi.hu>");
|
|
|
|
|
MODULE_DESCRIPTION("Filesystem in Userspace");
|
|
|
|
|
MODULE_LICENSE("GPL");
|
|
|
|
|
|
|
|
|
|
static kmem_cache_t *fuse_inode_cachep;
|
2006-01-17 14:14:35 +08:00
|
|
|
static struct subsystem connections_subsys;
|
|
|
|
|
|
|
|
|
|
struct fuse_conn_attr {
|
|
|
|
|
struct attribute attr;
|
|
|
|
|
ssize_t (*show)(struct fuse_conn *, char *);
|
|
|
|
|
ssize_t (*store)(struct fuse_conn *, const char *, size_t);
|
|
|
|
|
};
|
[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-10 04:10:26 +08:00
|
|
|
|
|
|
|
|
#define FUSE_SUPER_MAGIC 0x65735546
|
|
|
|
|
|
|
|
|
|
struct fuse_mount_data {
|
|
|
|
|
int fd;
|
|
|
|
|
unsigned rootmode;
|
|
|
|
|
unsigned user_id;
|
2005-09-10 04:10:34 +08:00
|
|
|
unsigned group_id;
|
2005-09-10 04:10:34 +08:00
|
|
|
unsigned fd_present : 1;
|
|
|
|
|
unsigned rootmode_present : 1;
|
|
|
|
|
unsigned user_id_present : 1;
|
|
|
|
|
unsigned group_id_present : 1;
|
2005-09-10 04:10:31 +08:00
|
|
|
unsigned flags;
|
2005-09-10 04:10:33 +08:00
|
|
|
unsigned max_read;
|
[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-10 04:10:26 +08:00
|
|
|
};
|
|
|
|
|
|
|
|
|
|
static struct inode *fuse_alloc_inode(struct super_block *sb)
|
|
|
|
|
{
|
|
|
|
|
struct inode *inode;
|
|
|
|
|
struct fuse_inode *fi;
|
|
|
|
|
|
|
|
|
|
inode = kmem_cache_alloc(fuse_inode_cachep, SLAB_KERNEL);
|
|
|
|
|
if (!inode)
|
|
|
|
|
return NULL;
|
|
|
|
|
|
|
|
|
|
fi = get_fuse_inode(inode);
|
|
|
|
|
fi->i_time = jiffies - 1;
|
|
|
|
|
fi->nodeid = 0;
|
2005-09-10 04:10:29 +08:00
|
|
|
fi->nlookup = 0;
|
2005-09-10 04:10:28 +08:00
|
|
|
fi->forget_req = fuse_request_alloc();
|
|
|
|
|
if (!fi->forget_req) {
|
|
|
|
|
kmem_cache_free(fuse_inode_cachep, inode);
|
|
|
|
|
return NULL;
|
|
|
|
|
}
|
[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-10 04:10:26 +08:00
|
|
|
|
|
|
|
|
return inode;
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
static void fuse_destroy_inode(struct inode *inode)
|
|
|
|
|
{
|
2005-09-10 04:10:28 +08:00
|
|
|
struct fuse_inode *fi = get_fuse_inode(inode);
|
|
|
|
|
if (fi->forget_req)
|
|
|
|
|
fuse_request_free(fi->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-10 04:10:26 +08:00
|
|
|
kmem_cache_free(fuse_inode_cachep, inode);
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
static void fuse_read_inode(struct inode *inode)
|
|
|
|
|
{
|
|
|
|
|
/* No op */
|
|
|
|
|
}
|
|
|
|
|
|
2005-09-10 04:10:28 +08:00
|
|
|
void fuse_send_forget(struct fuse_conn *fc, struct fuse_req *req,
|
2005-09-10 04:10:29 +08:00
|
|
|
unsigned long nodeid, u64 nlookup)
|
2005-09-10 04:10:28 +08:00
|
|
|
{
|
|
|
|
|
struct fuse_forget_in *inarg = &req->misc.forget_in;
|
2005-09-10 04:10:29 +08:00
|
|
|
inarg->nlookup = nlookup;
|
2005-09-10 04:10:28 +08:00
|
|
|
req->in.h.opcode = FUSE_FORGET;
|
|
|
|
|
req->in.h.nodeid = nodeid;
|
|
|
|
|
req->in.numargs = 1;
|
|
|
|
|
req->in.args[0].size = sizeof(struct fuse_forget_in);
|
|
|
|
|
req->in.args[0].value = inarg;
|
|
|
|
|
request_send_noreply(fc, 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-10 04:10:26 +08:00
|
|
|
static void fuse_clear_inode(struct inode *inode)
|
|
|
|
|
{
|
2005-09-10 04:10:31 +08:00
|
|
|
if (inode->i_sb->s_flags & MS_ACTIVE) {
|
|
|
|
|
struct fuse_conn *fc = get_fuse_conn(inode);
|
2005-09-10 04:10:28 +08:00
|
|
|
struct fuse_inode *fi = get_fuse_inode(inode);
|
2005-09-10 04:10:29 +08:00
|
|
|
fuse_send_forget(fc, fi->forget_req, fi->nodeid, fi->nlookup);
|
2005-09-10 04:10:28 +08:00
|
|
|
fi->forget_req = NULL;
|
|
|
|
|
}
|
[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-10 04:10:26 +08:00
|
|
|
}
|
|
|
|
|
|
|
|
|
|
void fuse_change_attributes(struct inode *inode, struct fuse_attr *attr)
|
|
|
|
|
{
|
|
|
|
|
if (S_ISREG(inode->i_mode) && i_size_read(inode) != attr->size)
|
|
|
|
|
invalidate_inode_pages(inode->i_mapping);
|
|
|
|
|
|
|
|
|
|
inode->i_ino = attr->ino;
|
|
|
|
|
inode->i_mode = (inode->i_mode & S_IFMT) + (attr->mode & 07777);
|
|
|
|
|
inode->i_nlink = attr->nlink;
|
|
|
|
|
inode->i_uid = attr->uid;
|
|
|
|
|
inode->i_gid = attr->gid;
|
|
|
|
|
i_size_write(inode, attr->size);
|
|
|
|
|
inode->i_blksize = PAGE_CACHE_SIZE;
|
|
|
|
|
inode->i_blocks = attr->blocks;
|
|
|
|
|
inode->i_atime.tv_sec = attr->atime;
|
|
|
|
|
inode->i_atime.tv_nsec = attr->atimensec;
|
|
|
|
|
inode->i_mtime.tv_sec = attr->mtime;
|
|
|
|
|
inode->i_mtime.tv_nsec = attr->mtimensec;
|
|
|
|
|
inode->i_ctime.tv_sec = attr->ctime;
|
|
|
|
|
inode->i_ctime.tv_nsec = attr->ctimensec;
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
static void fuse_init_inode(struct inode *inode, struct fuse_attr *attr)
|
|
|
|
|
{
|
|
|
|
|
inode->i_mode = attr->mode & S_IFMT;
|
|
|
|
|
i_size_write(inode, attr->size);
|
2005-09-10 04:10:28 +08:00
|
|
|
if (S_ISREG(inode->i_mode)) {
|
|
|
|
|
fuse_init_common(inode);
|
2005-09-10 04:10:30 +08:00
|
|
|
fuse_init_file_inode(inode);
|
2005-09-10 04:10:28 +08:00
|
|
|
} else if (S_ISDIR(inode->i_mode))
|
|
|
|
|
fuse_init_dir(inode);
|
|
|
|
|
else if (S_ISLNK(inode->i_mode))
|
|
|
|
|
fuse_init_symlink(inode);
|
|
|
|
|
else if (S_ISCHR(inode->i_mode) || S_ISBLK(inode->i_mode) ||
|
|
|
|
|
S_ISFIFO(inode->i_mode) || S_ISSOCK(inode->i_mode)) {
|
|
|
|
|
fuse_init_common(inode);
|
|
|
|
|
init_special_inode(inode, inode->i_mode,
|
|
|
|
|
new_decode_dev(attr->rdev));
|
2006-01-06 16:19:43 +08:00
|
|
|
} else
|
|
|
|
|
BUG();
|
[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-10 04:10:26 +08:00
|
|
|
}
|
|
|
|
|
|
|
|
|
|
static int fuse_inode_eq(struct inode *inode, void *_nodeidp)
|
|
|
|
|
{
|
|
|
|
|
unsigned long nodeid = *(unsigned long *) _nodeidp;
|
|
|
|
|
if (get_node_id(inode) == nodeid)
|
|
|
|
|
return 1;
|
|
|
|
|
else
|
|
|
|
|
return 0;
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
static int fuse_inode_set(struct inode *inode, void *_nodeidp)
|
|
|
|
|
{
|
|
|
|
|
unsigned long nodeid = *(unsigned long *) _nodeidp;
|
|
|
|
|
get_fuse_inode(inode)->nodeid = nodeid;
|
|
|
|
|
return 0;
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
struct inode *fuse_iget(struct super_block *sb, unsigned long nodeid,
|
2005-09-10 04:10:29 +08:00
|
|
|
int generation, struct fuse_attr *attr)
|
[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-10 04:10:26 +08:00
|
|
|
{
|
|
|
|
|
struct inode *inode;
|
2005-09-10 04:10:29 +08:00
|
|
|
struct fuse_inode *fi;
|
[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-10 04:10:26 +08:00
|
|
|
struct fuse_conn *fc = get_fuse_conn_super(sb);
|
|
|
|
|
int retried = 0;
|
|
|
|
|
|
|
|
|
|
retry:
|
|
|
|
|
inode = iget5_locked(sb, nodeid, fuse_inode_eq, fuse_inode_set, &nodeid);
|
|
|
|
|
if (!inode)
|
|
|
|
|
return NULL;
|
|
|
|
|
|
|
|
|
|
if ((inode->i_state & I_NEW)) {
|
2005-09-10 04:10:38 +08:00
|
|
|
inode->i_flags |= S_NOATIME|S_NOCMTIME;
|
[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-10 04:10:26 +08:00
|
|
|
inode->i_generation = generation;
|
|
|
|
|
inode->i_data.backing_dev_info = &fc->bdi;
|
|
|
|
|
fuse_init_inode(inode, attr);
|
|
|
|
|
unlock_new_inode(inode);
|
|
|
|
|
} else if ((inode->i_mode ^ attr->mode) & S_IFMT) {
|
|
|
|
|
BUG_ON(retried);
|
|
|
|
|
/* Inode has changed type, any I/O on the old should fail */
|
|
|
|
|
make_bad_inode(inode);
|
|
|
|
|
iput(inode);
|
|
|
|
|
retried = 1;
|
|
|
|
|
goto retry;
|
|
|
|
|
}
|
|
|
|
|
|
2005-09-10 04:10:29 +08:00
|
|
|
fi = get_fuse_inode(inode);
|
|
|
|
|
fi->nlookup ++;
|
[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-10 04:10:26 +08:00
|
|
|
fuse_change_attributes(inode, attr);
|
|
|
|
|
return inode;
|
|
|
|
|
}
|
|
|
|
|
|
2006-01-17 14:14:41 +08:00
|
|
|
static void fuse_umount_begin(struct super_block *sb)
|
|
|
|
|
{
|
|
|
|
|
fuse_abort_conn(get_fuse_conn_super(sb));
|
|
|
|
|
}
|
|
|
|
|
|
[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-10 04:10:26 +08:00
|
|
|
static void fuse_put_super(struct super_block *sb)
|
|
|
|
|
{
|
|
|
|
|
struct fuse_conn *fc = get_fuse_conn_super(sb);
|
|
|
|
|
|
2006-04-11 13:54:55 +08:00
|
|
|
spin_lock(&fc->lock);
|
2006-01-17 14:14:34 +08:00
|
|
|
fc->connected = 0;
|
2006-04-12 03:14:26 +08:00
|
|
|
while (!list_empty(&fc->background)) {
|
|
|
|
|
struct fuse_req *req = list_entry(fc->background.next,
|
|
|
|
|
struct fuse_req, bg_entry);
|
|
|
|
|
struct inode *inode = req->inode;
|
|
|
|
|
struct inode *inode2 = req->inode2;
|
|
|
|
|
|
|
|
|
|
/* File would hold a reference to vfsmount */
|
|
|
|
|
BUG_ON(req->file);
|
|
|
|
|
req->inode = NULL;
|
|
|
|
|
req->inode2 = NULL;
|
|
|
|
|
fuse_remove_background(fc, req);
|
|
|
|
|
|
|
|
|
|
spin_unlock(&fc->lock);
|
|
|
|
|
iput(inode);
|
|
|
|
|
iput(inode2);
|
|
|
|
|
spin_lock(&fc->lock);
|
|
|
|
|
}
|
2006-04-11 13:54:55 +08:00
|
|
|
spin_unlock(&fc->lock);
|
2005-09-10 04:10:27 +08:00
|
|
|
/* Flush all readers on this fs */
|
2006-04-11 13:54:52 +08:00
|
|
|
kill_fasync(&fc->fasync, SIGIO, POLL_IN);
|
2005-09-10 04:10:27 +08:00
|
|
|
wake_up_all(&fc->waitq);
|
2006-01-17 14:14:35 +08:00
|
|
|
kobject_del(&fc->kobj);
|
|
|
|
|
kobject_put(&fc->kobj);
|
[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-10 04:10:26 +08:00
|
|
|
}
|
|
|
|
|
|
2005-09-10 04:10:28 +08:00
|
|
|
static void convert_fuse_statfs(struct kstatfs *stbuf, struct fuse_kstatfs *attr)
|
|
|
|
|
{
|
|
|
|
|
stbuf->f_type = FUSE_SUPER_MAGIC;
|
|
|
|
|
stbuf->f_bsize = attr->bsize;
|
2006-01-06 16:19:37 +08:00
|
|
|
stbuf->f_frsize = attr->frsize;
|
2005-09-10 04:10:28 +08:00
|
|
|
stbuf->f_blocks = attr->blocks;
|
|
|
|
|
stbuf->f_bfree = attr->bfree;
|
|
|
|
|
stbuf->f_bavail = attr->bavail;
|
|
|
|
|
stbuf->f_files = attr->files;
|
|
|
|
|
stbuf->f_ffree = attr->ffree;
|
|
|
|
|
stbuf->f_namelen = attr->namelen;
|
|
|
|
|
/* fsid is left zero */
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
static int fuse_statfs(struct super_block *sb, struct kstatfs *buf)
|
|
|
|
|
{
|
|
|
|
|
struct fuse_conn *fc = get_fuse_conn_super(sb);
|
|
|
|
|
struct fuse_req *req;
|
|
|
|
|
struct fuse_statfs_out outarg;
|
|
|
|
|
int err;
|
|
|
|
|
|
2006-04-11 13:54:58 +08:00
|
|
|
req = fuse_get_req(fc);
|
|
|
|
|
if (IS_ERR(req))
|
|
|
|
|
return PTR_ERR(req);
|
2005-09-10 04:10:28 +08:00
|
|
|
|
2006-01-06 16:19:37 +08:00
|
|
|
memset(&outarg, 0, sizeof(outarg));
|
2005-09-10 04:10:28 +08:00
|
|
|
req->in.numargs = 0;
|
|
|
|
|
req->in.h.opcode = FUSE_STATFS;
|
|
|
|
|
req->out.numargs = 1;
|
2006-01-06 16:19:37 +08:00
|
|
|
req->out.args[0].size =
|
|
|
|
|
fc->minor < 4 ? FUSE_COMPAT_STATFS_SIZE : sizeof(outarg);
|
2005-09-10 04:10:28 +08:00
|
|
|
req->out.args[0].value = &outarg;
|
|
|
|
|
request_send(fc, req);
|
|
|
|
|
err = req->out.h.error;
|
|
|
|
|
if (!err)
|
|
|
|
|
convert_fuse_statfs(buf, &outarg.st);
|
|
|
|
|
fuse_put_request(fc, req);
|
|
|
|
|
return err;
|
|
|
|
|
}
|
|
|
|
|
|
[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-10 04:10:26 +08:00
|
|
|
enum {
|
|
|
|
|
OPT_FD,
|
|
|
|
|
OPT_ROOTMODE,
|
|
|
|
|
OPT_USER_ID,
|
2005-09-10 04:10:34 +08:00
|
|
|
OPT_GROUP_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-10 04:10:26 +08:00
|
|
|
OPT_DEFAULT_PERMISSIONS,
|
|
|
|
|
OPT_ALLOW_OTHER,
|
2005-09-10 04:10:33 +08:00
|
|
|
OPT_MAX_READ,
|
[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-10 04:10:26 +08:00
|
|
|
OPT_ERR
|
|
|
|
|
};
|
|
|
|
|
|
|
|
|
|
static match_table_t tokens = {
|
|
|
|
|
{OPT_FD, "fd=%u"},
|
|
|
|
|
{OPT_ROOTMODE, "rootmode=%o"},
|
|
|
|
|
{OPT_USER_ID, "user_id=%u"},
|
2005-09-10 04:10:34 +08:00
|
|
|
{OPT_GROUP_ID, "group_id=%u"},
|
[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-10 04:10:26 +08:00
|
|
|
{OPT_DEFAULT_PERMISSIONS, "default_permissions"},
|
|
|
|
|
{OPT_ALLOW_OTHER, "allow_other"},
|
2005-09-10 04:10:33 +08:00
|
|
|
{OPT_MAX_READ, "max_read=%u"},
|
[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-10 04:10:26 +08:00
|
|
|
{OPT_ERR, NULL}
|
|
|
|
|
};
|
|
|
|
|
|
|
|
|
|
static int parse_fuse_opt(char *opt, struct fuse_mount_data *d)
|
|
|
|
|
{
|
|
|
|
|
char *p;
|
|
|
|
|
memset(d, 0, sizeof(struct fuse_mount_data));
|
2005-09-10 04:10:33 +08:00
|
|
|
d->max_read = ~0;
|
[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-10 04:10:26 +08:00
|
|
|
|
|
|
|
|
while ((p = strsep(&opt, ",")) != NULL) {
|
|
|
|
|
int token;
|
|
|
|
|
int value;
|
|
|
|
|
substring_t args[MAX_OPT_ARGS];
|
|
|
|
|
if (!*p)
|
|
|
|
|
continue;
|
|
|
|
|
|
|
|
|
|
token = match_token(p, tokens, args);
|
|
|
|
|
switch (token) {
|
|
|
|
|
case OPT_FD:
|
|
|
|
|
if (match_int(&args[0], &value))
|
|
|
|
|
return 0;
|
|
|
|
|
d->fd = value;
|
2005-09-10 04:10:34 +08:00
|
|
|
d->fd_present = 1;
|
[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-10 04:10:26 +08:00
|
|
|
break;
|
|
|
|
|
|
|
|
|
|
case OPT_ROOTMODE:
|
|
|
|
|
if (match_octal(&args[0], &value))
|
|
|
|
|
return 0;
|
|
|
|
|
d->rootmode = value;
|
2005-09-10 04:10:34 +08:00
|
|
|
d->rootmode_present = 1;
|
[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-10 04:10:26 +08:00
|
|
|
break;
|
|
|
|
|
|
|
|
|
|
case OPT_USER_ID:
|
|
|
|
|
if (match_int(&args[0], &value))
|
|
|
|
|
return 0;
|
|
|
|
|
d->user_id = value;
|
2005-09-10 04:10:34 +08:00
|
|
|
d->user_id_present = 1;
|
[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-10 04:10:26 +08:00
|
|
|
break;
|
|
|
|
|
|
2005-09-10 04:10:34 +08:00
|
|
|
case OPT_GROUP_ID:
|
|
|
|
|
if (match_int(&args[0], &value))
|
|
|
|
|
return 0;
|
|
|
|
|
d->group_id = value;
|
2005-09-10 04:10:34 +08:00
|
|
|
d->group_id_present = 1;
|
2005-09-10 04:10:34 +08:00
|
|
|
break;
|
|
|
|
|
|
2005-09-10 04:10:31 +08:00
|
|
|
case OPT_DEFAULT_PERMISSIONS:
|
|
|
|
|
d->flags |= FUSE_DEFAULT_PERMISSIONS;
|
|
|
|
|
break;
|
|
|
|
|
|
|
|
|
|
case OPT_ALLOW_OTHER:
|
|
|
|
|
d->flags |= FUSE_ALLOW_OTHER;
|
|
|
|
|
break;
|
|
|
|
|
|
2005-09-10 04:10:33 +08:00
|
|
|
case OPT_MAX_READ:
|
|
|
|
|
if (match_int(&args[0], &value))
|
|
|
|
|
return 0;
|
|
|
|
|
d->max_read = value;
|
|
|
|
|
break;
|
|
|
|
|
|
[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-10 04:10:26 +08:00
|
|
|
default:
|
|
|
|
|
return 0;
|
|
|
|
|
}
|
|
|
|
|
}
|
2005-09-10 04:10:34 +08:00
|
|
|
|
|
|
|
|
if (!d->fd_present || !d->rootmode_present ||
|
|
|
|
|
!d->user_id_present || !d->group_id_present)
|
[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-10 04:10:26 +08:00
|
|
|
return 0;
|
|
|
|
|
|
|
|
|
|
return 1;
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
static int fuse_show_options(struct seq_file *m, struct vfsmount *mnt)
|
|
|
|
|
{
|
|
|
|
|
struct fuse_conn *fc = get_fuse_conn_super(mnt->mnt_sb);
|
|
|
|
|
|
|
|
|
|
seq_printf(m, ",user_id=%u", fc->user_id);
|
2005-09-10 04:10:34 +08:00
|
|
|
seq_printf(m, ",group_id=%u", fc->group_id);
|
2005-09-10 04:10:31 +08:00
|
|
|
if (fc->flags & FUSE_DEFAULT_PERMISSIONS)
|
|
|
|
|
seq_puts(m, ",default_permissions");
|
|
|
|
|
if (fc->flags & FUSE_ALLOW_OTHER)
|
|
|
|
|
seq_puts(m, ",allow_other");
|
2005-09-10 04:10:33 +08:00
|
|
|
if (fc->max_read != ~0)
|
|
|
|
|
seq_printf(m, ",max_read=%u", fc->max_read);
|
[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-10 04:10:26 +08:00
|
|
|
return 0;
|
|
|
|
|
}
|
|
|
|
|
|
2006-01-17 14:14:35 +08:00
|
|
|
static void fuse_conn_release(struct kobject *kobj)
|
[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-10 04:10:26 +08:00
|
|
|
{
|
2006-04-11 13:54:58 +08:00
|
|
|
kfree(get_fuse_conn_kobj(kobj));
|
[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-10 04:10:26 +08:00
|
|
|
}
|
|
|
|
|
|
|
|
|
|
static struct fuse_conn *new_conn(void)
|
|
|
|
|
{
|
|
|
|
|
struct fuse_conn *fc;
|
|
|
|
|
|
2006-01-17 14:14:29 +08:00
|
|
|
fc = kzalloc(sizeof(*fc), GFP_KERNEL);
|
2006-01-17 14:14:35 +08:00
|
|
|
if (fc) {
|
2006-04-11 13:54:55 +08:00
|
|
|
spin_lock_init(&fc->lock);
|
2005-09-10 04:10:27 +08:00
|
|
|
init_waitqueue_head(&fc->waitq);
|
2006-04-11 13:54:59 +08:00
|
|
|
init_waitqueue_head(&fc->blocked_waitq);
|
2005-09-10 04:10:27 +08:00
|
|
|
INIT_LIST_HEAD(&fc->pending);
|
|
|
|
|
INIT_LIST_HEAD(&fc->processing);
|
2006-01-17 14:14:31 +08:00
|
|
|
INIT_LIST_HEAD(&fc->io);
|
2005-09-10 04:10:31 +08:00
|
|
|
INIT_LIST_HEAD(&fc->background);
|
2006-01-17 14:14:35 +08:00
|
|
|
kobj_set_kset_s(fc, connections_subsys);
|
|
|
|
|
kobject_init(&fc->kobj);
|
2006-01-17 14:14:52 +08:00
|
|
|
atomic_set(&fc->num_waiting, 0);
|
[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-10 04:10:26 +08:00
|
|
|
fc->bdi.ra_pages = (VM_MAX_READAHEAD * 1024) / PAGE_CACHE_SIZE;
|
|
|
|
|
fc->bdi.unplug_io_fn = default_unplug_io_fn;
|
2005-09-10 04:10:27 +08:00
|
|
|
fc->reqctr = 0;
|
2006-04-11 13:54:59 +08:00
|
|
|
fc->blocked = 1;
|
[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-10 04:10:26 +08:00
|
|
|
}
|
|
|
|
|
return fc;
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
static struct inode *get_root_inode(struct super_block *sb, unsigned mode)
|
|
|
|
|
{
|
|
|
|
|
struct fuse_attr attr;
|
|
|
|
|
memset(&attr, 0, sizeof(attr));
|
|
|
|
|
|
|
|
|
|
attr.mode = mode;
|
|
|
|
|
attr.ino = FUSE_ROOT_ID;
|
2005-09-10 04:10:29 +08:00
|
|
|
return fuse_iget(sb, 1, 0, &attr);
|
[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-10 04:10:26 +08:00
|
|
|
}
|
|
|
|
|
|
|
|
|
|
static struct super_operations fuse_super_operations = {
|
|
|
|
|
.alloc_inode = fuse_alloc_inode,
|
|
|
|
|
.destroy_inode = fuse_destroy_inode,
|
|
|
|
|
.read_inode = fuse_read_inode,
|
|
|
|
|
.clear_inode = fuse_clear_inode,
|
|
|
|
|
.put_super = fuse_put_super,
|
2006-01-17 14:14:41 +08:00
|
|
|
.umount_begin = fuse_umount_begin,
|
2005-09-10 04:10:28 +08:00
|
|
|
.statfs = fuse_statfs,
|
[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-10 04:10:26 +08:00
|
|
|
.show_options = fuse_show_options,
|
|
|
|
|
};
|
|
|
|
|
|
2006-01-17 14:14:44 +08:00
|
|
|
static void process_init_reply(struct fuse_conn *fc, struct fuse_req *req)
|
|
|
|
|
{
|
|
|
|
|
struct fuse_init_out *arg = &req->misc.init_out;
|
|
|
|
|
|
|
|
|
|
if (req->out.h.error || arg->major != FUSE_KERNEL_VERSION)
|
|
|
|
|
fc->conn_error = 1;
|
|
|
|
|
else {
|
2006-02-01 19:04:40 +08:00
|
|
|
unsigned long ra_pages;
|
|
|
|
|
|
|
|
|
|
if (arg->minor >= 6) {
|
|
|
|
|
ra_pages = arg->max_readahead / PAGE_CACHE_SIZE;
|
|
|
|
|
if (arg->flags & FUSE_ASYNC_READ)
|
|
|
|
|
fc->async_read = 1;
|
|
|
|
|
} else
|
|
|
|
|
ra_pages = fc->max_read / PAGE_CACHE_SIZE;
|
|
|
|
|
|
|
|
|
|
fc->bdi.ra_pages = min(fc->bdi.ra_pages, ra_pages);
|
2006-01-17 14:14:44 +08:00
|
|
|
fc->minor = arg->minor;
|
|
|
|
|
fc->max_write = arg->minor < 5 ? 4096 : arg->max_write;
|
|
|
|
|
}
|
|
|
|
|
fuse_put_request(fc, req);
|
2006-04-11 13:54:59 +08:00
|
|
|
fc->blocked = 0;
|
|
|
|
|
wake_up_all(&fc->blocked_waitq);
|
2006-01-17 14:14:44 +08:00
|
|
|
}
|
|
|
|
|
|
2006-04-11 13:54:58 +08:00
|
|
|
static void fuse_send_init(struct fuse_conn *fc, struct fuse_req *req)
|
2006-01-17 14:14:44 +08:00
|
|
|
{
|
|
|
|
|
struct fuse_init_in *arg = &req->misc.init_in;
|
2006-01-17 14:14:52 +08:00
|
|
|
|
2006-01-17 14:14:44 +08:00
|
|
|
arg->major = FUSE_KERNEL_VERSION;
|
|
|
|
|
arg->minor = FUSE_KERNEL_MINOR_VERSION;
|
2006-02-01 19:04:40 +08:00
|
|
|
arg->max_readahead = fc->bdi.ra_pages * PAGE_CACHE_SIZE;
|
|
|
|
|
arg->flags |= FUSE_ASYNC_READ;
|
2006-01-17 14:14:44 +08:00
|
|
|
req->in.h.opcode = FUSE_INIT;
|
|
|
|
|
req->in.numargs = 1;
|
|
|
|
|
req->in.args[0].size = sizeof(*arg);
|
|
|
|
|
req->in.args[0].value = arg;
|
|
|
|
|
req->out.numargs = 1;
|
|
|
|
|
/* Variable length arguement used for backward compatibility
|
|
|
|
|
with interface version < 7.5. Rest of init_out is zeroed
|
|
|
|
|
by do_get_request(), so a short reply is not a problem */
|
|
|
|
|
req->out.argvar = 1;
|
|
|
|
|
req->out.args[0].size = sizeof(struct fuse_init_out);
|
|
|
|
|
req->out.args[0].value = &req->misc.init_out;
|
|
|
|
|
req->end = process_init_reply;
|
|
|
|
|
request_send_background(fc, req);
|
|
|
|
|
}
|
|
|
|
|
|
2006-01-17 14:14:35 +08:00
|
|
|
static unsigned long long conn_id(void)
|
|
|
|
|
{
|
2006-04-11 13:54:55 +08:00
|
|
|
/* BKL is held for ->get_sb() */
|
2006-01-17 14:14:35 +08:00
|
|
|
static unsigned long long ctr = 1;
|
2006-04-11 13:54:55 +08:00
|
|
|
return ctr++;
|
2006-01-17 14:14:35 +08: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-10 04:10:26 +08:00
|
|
|
static int fuse_fill_super(struct super_block *sb, void *data, int silent)
|
|
|
|
|
{
|
|
|
|
|
struct fuse_conn *fc;
|
|
|
|
|
struct inode *root;
|
|
|
|
|
struct fuse_mount_data d;
|
|
|
|
|
struct file *file;
|
2006-01-17 14:14:35 +08:00
|
|
|
struct dentry *root_dentry;
|
2006-04-11 13:54:58 +08:00
|
|
|
struct fuse_req *init_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-10 04:10:26 +08:00
|
|
|
int err;
|
|
|
|
|
|
|
|
|
|
if (!parse_fuse_opt((char *) data, &d))
|
|
|
|
|
return -EINVAL;
|
|
|
|
|
|
|
|
|
|
sb->s_blocksize = PAGE_CACHE_SIZE;
|
|
|
|
|
sb->s_blocksize_bits = PAGE_CACHE_SHIFT;
|
|
|
|
|
sb->s_magic = FUSE_SUPER_MAGIC;
|
|
|
|
|
sb->s_op = &fuse_super_operations;
|
|
|
|
|
sb->s_maxbytes = MAX_LFS_FILESIZE;
|
|
|
|
|
|
|
|
|
|
file = fget(d.fd);
|
|
|
|
|
if (!file)
|
|
|
|
|
return -EINVAL;
|
|
|
|
|
|
2006-04-11 13:54:55 +08:00
|
|
|
if (file->f_op != &fuse_dev_operations)
|
|
|
|
|
return -EINVAL;
|
|
|
|
|
|
|
|
|
|
/* Setting file->private_data can't race with other mount()
|
|
|
|
|
instances, since BKL is held for ->get_sb() */
|
|
|
|
|
if (file->private_data)
|
|
|
|
|
return -EINVAL;
|
|
|
|
|
|
|
|
|
|
fc = new_conn();
|
|
|
|
|
if (!fc)
|
|
|
|
|
return -ENOMEM;
|
[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-10 04:10:26 +08:00
|
|
|
|
2005-09-10 04:10:31 +08:00
|
|
|
fc->flags = d.flags;
|
[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-10 04:10:26 +08:00
|
|
|
fc->user_id = d.user_id;
|
2005-09-10 04:10:34 +08:00
|
|
|
fc->group_id = d.group_id;
|
2005-09-10 04:10:33 +08:00
|
|
|
fc->max_read = d.max_read;
|
[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-10 04:10:26 +08:00
|
|
|
|
2006-01-17 14:14:35 +08:00
|
|
|
/* Used by get_root_inode() */
|
|
|
|
|
sb->s_fs_info = fc;
|
|
|
|
|
|
[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-10 04:10:26 +08:00
|
|
|
err = -ENOMEM;
|
|
|
|
|
root = get_root_inode(sb, d.rootmode);
|
2006-01-17 14:14:35 +08:00
|
|
|
if (!root)
|
[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-10 04:10:26 +08:00
|
|
|
goto err;
|
|
|
|
|
|
2006-01-17 14:14:35 +08:00
|
|
|
root_dentry = d_alloc_root(root);
|
|
|
|
|
if (!root_dentry) {
|
[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-10 04:10:26 +08:00
|
|
|
iput(root);
|
|
|
|
|
goto err;
|
|
|
|
|
}
|
2006-01-17 14:14:35 +08:00
|
|
|
|
2006-04-11 13:54:58 +08:00
|
|
|
init_req = fuse_request_alloc();
|
|
|
|
|
if (!init_req)
|
|
|
|
|
goto err_put_root;
|
|
|
|
|
|
2006-01-17 14:14:35 +08:00
|
|
|
err = kobject_set_name(&fc->kobj, "%llu", conn_id());
|
|
|
|
|
if (err)
|
2006-04-11 13:54:58 +08:00
|
|
|
goto err_free_req;
|
2006-01-17 14:14:35 +08:00
|
|
|
|
|
|
|
|
err = kobject_add(&fc->kobj);
|
|
|
|
|
if (err)
|
2006-04-11 13:54:58 +08:00
|
|
|
goto err_free_req;
|
2006-01-17 14:14:35 +08:00
|
|
|
|
|
|
|
|
sb->s_root = root_dentry;
|
|
|
|
|
fc->connected = 1;
|
2006-04-11 13:54:55 +08:00
|
|
|
kobject_get(&fc->kobj);
|
|
|
|
|
file->private_data = fc;
|
|
|
|
|
/*
|
|
|
|
|
* atomic_dec_and_test() in fput() provides the necessary
|
|
|
|
|
* memory barrier for file->private_data to be visible on all
|
|
|
|
|
* CPUs after this
|
|
|
|
|
*/
|
|
|
|
|
fput(file);
|
2006-01-17 14:14:35 +08:00
|
|
|
|
2006-04-11 13:54:58 +08:00
|
|
|
fuse_send_init(fc, init_req);
|
2006-01-17 14:14:35 +08: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-10 04:10:26 +08:00
|
|
|
return 0;
|
|
|
|
|
|
2006-04-11 13:54:58 +08:00
|
|
|
err_free_req:
|
|
|
|
|
fuse_request_free(init_req);
|
2006-01-17 14:14:35 +08:00
|
|
|
err_put_root:
|
|
|
|
|
dput(root_dentry);
|
[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-10 04:10:26 +08:00
|
|
|
err:
|
2006-04-11 13:54:55 +08:00
|
|
|
fput(file);
|
2006-01-17 14:14:35 +08:00
|
|
|
kobject_put(&fc->kobj);
|
[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-10 04:10:26 +08:00
|
|
|
return err;
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
static struct super_block *fuse_get_sb(struct file_system_type *fs_type,
|
|
|
|
|
int flags, const char *dev_name,
|
|
|
|
|
void *raw_data)
|
|
|
|
|
{
|
|
|
|
|
return get_sb_nodev(fs_type, flags, raw_data, fuse_fill_super);
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
static struct file_system_type fuse_fs_type = {
|
|
|
|
|
.owner = THIS_MODULE,
|
|
|
|
|
.name = "fuse",
|
|
|
|
|
.get_sb = fuse_get_sb,
|
|
|
|
|
.kill_sb = kill_anon_super,
|
|
|
|
|
};
|
|
|
|
|
|
2006-01-17 14:14:38 +08:00
|
|
|
static ssize_t fuse_conn_waiting_show(struct fuse_conn *fc, char *page)
|
|
|
|
|
{
|
|
|
|
|
return sprintf(page, "%i\n", atomic_read(&fc->num_waiting));
|
|
|
|
|
}
|
|
|
|
|
|
2006-01-17 14:14:41 +08:00
|
|
|
static ssize_t fuse_conn_abort_store(struct fuse_conn *fc, const char *page,
|
|
|
|
|
size_t count)
|
|
|
|
|
{
|
|
|
|
|
fuse_abort_conn(fc);
|
|
|
|
|
return count;
|
|
|
|
|
}
|
|
|
|
|
|
2006-01-17 14:14:38 +08:00
|
|
|
static struct fuse_conn_attr fuse_conn_waiting =
|
|
|
|
|
__ATTR(waiting, 0400, fuse_conn_waiting_show, NULL);
|
2006-01-17 14:14:41 +08:00
|
|
|
static struct fuse_conn_attr fuse_conn_abort =
|
|
|
|
|
__ATTR(abort, 0600, NULL, fuse_conn_abort_store);
|
2006-01-17 14:14:38 +08:00
|
|
|
|
2006-01-17 14:14:35 +08:00
|
|
|
static struct attribute *fuse_conn_attrs[] = {
|
2006-01-17 14:14:38 +08:00
|
|
|
&fuse_conn_waiting.attr,
|
2006-01-17 14:14:41 +08:00
|
|
|
&fuse_conn_abort.attr,
|
2006-01-17 14:14:35 +08:00
|
|
|
NULL,
|
|
|
|
|
};
|
|
|
|
|
|
|
|
|
|
static ssize_t fuse_conn_attr_show(struct kobject *kobj,
|
|
|
|
|
struct attribute *attr,
|
|
|
|
|
char *page)
|
|
|
|
|
{
|
|
|
|
|
struct fuse_conn_attr *fca =
|
|
|
|
|
container_of(attr, struct fuse_conn_attr, attr);
|
|
|
|
|
|
|
|
|
|
if (fca->show)
|
|
|
|
|
return fca->show(get_fuse_conn_kobj(kobj), page);
|
|
|
|
|
else
|
|
|
|
|
return -EACCES;
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
static ssize_t fuse_conn_attr_store(struct kobject *kobj,
|
|
|
|
|
struct attribute *attr,
|
|
|
|
|
const char *page, size_t count)
|
|
|
|
|
{
|
|
|
|
|
struct fuse_conn_attr *fca =
|
|
|
|
|
container_of(attr, struct fuse_conn_attr, attr);
|
|
|
|
|
|
|
|
|
|
if (fca->store)
|
|
|
|
|
return fca->store(get_fuse_conn_kobj(kobj), page, count);
|
|
|
|
|
else
|
|
|
|
|
return -EACCES;
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
static struct sysfs_ops fuse_conn_sysfs_ops = {
|
|
|
|
|
.show = &fuse_conn_attr_show,
|
|
|
|
|
.store = &fuse_conn_attr_store,
|
|
|
|
|
};
|
|
|
|
|
|
|
|
|
|
static struct kobj_type ktype_fuse_conn = {
|
|
|
|
|
.release = fuse_conn_release,
|
|
|
|
|
.sysfs_ops = &fuse_conn_sysfs_ops,
|
|
|
|
|
.default_attrs = fuse_conn_attrs,
|
|
|
|
|
};
|
|
|
|
|
|
|
|
|
|
static decl_subsys(fuse, NULL, NULL);
|
|
|
|
|
static decl_subsys(connections, &ktype_fuse_conn, NULL);
|
|
|
|
|
|
[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-10 04:10:26 +08:00
|
|
|
static void fuse_inode_init_once(void *foo, kmem_cache_t *cachep,
|
|
|
|
|
unsigned long flags)
|
|
|
|
|
{
|
|
|
|
|
struct inode * inode = foo;
|
|
|
|
|
|
|
|
|
|
if ((flags & (SLAB_CTOR_VERIFY|SLAB_CTOR_CONSTRUCTOR)) ==
|
|
|
|
|
SLAB_CTOR_CONSTRUCTOR)
|
|
|
|
|
inode_init_once(inode);
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
static int __init fuse_fs_init(void)
|
|
|
|
|
{
|
|
|
|
|
int err;
|
|
|
|
|
|
|
|
|
|
err = register_filesystem(&fuse_fs_type);
|
|
|
|
|
if (err)
|
|
|
|
|
printk("fuse: failed to register filesystem\n");
|
|
|
|
|
else {
|
|
|
|
|
fuse_inode_cachep = kmem_cache_create("fuse_inode",
|
|
|
|
|
sizeof(struct fuse_inode),
|
|
|
|
|
0, SLAB_HWCACHE_ALIGN,
|
|
|
|
|
fuse_inode_init_once, NULL);
|
|
|
|
|
if (!fuse_inode_cachep) {
|
|
|
|
|
unregister_filesystem(&fuse_fs_type);
|
|
|
|
|
err = -ENOMEM;
|
|
|
|
|
}
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
return err;
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
static void fuse_fs_cleanup(void)
|
|
|
|
|
{
|
|
|
|
|
unregister_filesystem(&fuse_fs_type);
|
|
|
|
|
kmem_cache_destroy(fuse_inode_cachep);
|
|
|
|
|
}
|
|
|
|
|
|
2006-01-17 14:14:35 +08:00
|
|
|
static int fuse_sysfs_init(void)
|
|
|
|
|
{
|
|
|
|
|
int err;
|
|
|
|
|
|
|
|
|
|
kset_set_kset_s(&fuse_subsys, fs_subsys);
|
|
|
|
|
err = subsystem_register(&fuse_subsys);
|
|
|
|
|
if (err)
|
|
|
|
|
goto out_err;
|
|
|
|
|
|
|
|
|
|
kset_set_kset_s(&connections_subsys, fuse_subsys);
|
|
|
|
|
err = subsystem_register(&connections_subsys);
|
|
|
|
|
if (err)
|
|
|
|
|
goto out_fuse_unregister;
|
|
|
|
|
|
|
|
|
|
return 0;
|
|
|
|
|
|
|
|
|
|
out_fuse_unregister:
|
|
|
|
|
subsystem_unregister(&fuse_subsys);
|
|
|
|
|
out_err:
|
|
|
|
|
return err;
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
static void fuse_sysfs_cleanup(void)
|
|
|
|
|
{
|
|
|
|
|
subsystem_unregister(&connections_subsys);
|
|
|
|
|
subsystem_unregister(&fuse_subsys);
|
|
|
|
|
}
|
|
|
|
|
|
[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-10 04:10:26 +08:00
|
|
|
static int __init fuse_init(void)
|
|
|
|
|
{
|
|
|
|
|
int res;
|
|
|
|
|
|
|
|
|
|
printk("fuse init (API version %i.%i)\n",
|
|
|
|
|
FUSE_KERNEL_VERSION, FUSE_KERNEL_MINOR_VERSION);
|
|
|
|
|
|
|
|
|
|
res = fuse_fs_init();
|
|
|
|
|
if (res)
|
|
|
|
|
goto err;
|
|
|
|
|
|
2005-09-10 04:10:27 +08:00
|
|
|
res = fuse_dev_init();
|
|
|
|
|
if (res)
|
|
|
|
|
goto err_fs_cleanup;
|
|
|
|
|
|
2006-01-17 14:14:35 +08:00
|
|
|
res = fuse_sysfs_init();
|
|
|
|
|
if (res)
|
|
|
|
|
goto err_dev_cleanup;
|
|
|
|
|
|
[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-10 04:10:26 +08:00
|
|
|
return 0;
|
|
|
|
|
|
2006-01-17 14:14:35 +08:00
|
|
|
err_dev_cleanup:
|
|
|
|
|
fuse_dev_cleanup();
|
2005-09-10 04:10:27 +08:00
|
|
|
err_fs_cleanup:
|
|
|
|
|
fuse_fs_cleanup();
|
[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-10 04:10:26 +08:00
|
|
|
err:
|
|
|
|
|
return res;
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
static void __exit fuse_exit(void)
|
|
|
|
|
{
|
|
|
|
|
printk(KERN_DEBUG "fuse exit\n");
|
|
|
|
|
|
2006-01-17 14:14:35 +08:00
|
|
|
fuse_sysfs_cleanup();
|
[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-10 04:10:26 +08:00
|
|
|
fuse_fs_cleanup();
|
2005-09-10 04:10:27 +08:00
|
|
|
fuse_dev_cleanup();
|
[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-10 04:10:26 +08:00
|
|
|
}
|
|
|
|
|
|
|
|
|
|
module_init(fuse_init);
|
|
|
|
|
module_exit(fuse_exit);
|