[PATCH] FUSE - core
This patch adds FUSE core.
This contains the following files:
o inode.c
- superblock operations (alloc_inode, destroy_inode, read_inode,
clear_inode, put_super, show_options)
- registers FUSE filesystem
o fuse_i.h
- private header file
Requirements
============
The most important difference between orinary filesystems and FUSE is
the fact, that the filesystem data/metadata is provided by a userspace
process run with the privileges of the mount "owner" instead of the
kernel, or some remote entity usually running with elevated
privileges.
The security implication of this is that a non-privileged user must
not be able to use this capability to compromise the system. Obvious
requirements arising from this are:
- mount owner should not be able to get elevated privileges with the
help of the mounted filesystem
- mount owner should not be able to induce undesired behavior in
other users' or the super user's processes
- mount owner should not get illegitimate access to information from
other users' and the super user's processes
These are currently ensured with the following constraints:
1) mount is only allowed to directory or file which the mount owner
can modify without limitation (write access + no sticky bit for
directories)
2) nosuid,nodev mount options are forced
3) any process running with fsuid different from the owner is denied
all access to the filesystem
1) and 2) are ensured by the "fusermount" mount utility which is a
setuid root application doing the actual mount operation.
3) is ensured by a check in the permission() method in kernel
I started thinking about doing 3) in a different way because Christoph
H. made a big deal out of it, saying that FUSE is unacceptable into
mainline in this form.
The suggested use of private namespaces would be OK, but in their
current form have many limitations that make their use impractical (as
discussed in this thread).
Suggested improvements that would address these limitations:
- implement shared subtrees
- allow a process to join an existing namespace (make namespaces
first-class objects)
- implement the namespace creation/joining in a PAM module
With all that in place the check of owner against current->fsuid may
be removed from the FUSE kernel module, without compromising the
security requirements.
Suid programs still interesting questions, since they get access even
to the private namespace causing some information leak (exact
order/timing of filesystem operations performed), giving some
ptrace-like capabilities to unprivileged users. BTW this problem is
not strictly limited to the namespace approach, since suid programs
setting fsuid and accessing users' files will succeed with the current
approach too.
Signed-off-by: Miklos Szeredi <miklos@szeredi.hu>
Signed-off-by: Andrew Morton <akpm@osdl.org>
Signed-off-by: Linus Torvalds <torvalds@osdl.org>
2005-09-09 16:10:26 -04:00
|
|
|
/*
|
|
|
|
FUSE: Filesystem in Userspace
|
|
|
|
Copyright (C) 2001-2005 Miklos Szeredi <miklos@szeredi.hu>
|
|
|
|
|
|
|
|
This program can be distributed under the terms of the GNU GPL.
|
|
|
|
See the file COPYING.
|
|
|
|
*/
|
|
|
|
|
|
|
|
/* This file defines the kernel interface of FUSE */
|
|
|
|
|
|
|
|
#include <asm/types.h>
|
|
|
|
|
|
|
|
/** Version number of this interface */
|
2005-09-09 16:10:27 -04:00
|
|
|
#define FUSE_KERNEL_VERSION 6
|
[PATCH] FUSE - core
This patch adds FUSE core.
This contains the following files:
o inode.c
- superblock operations (alloc_inode, destroy_inode, read_inode,
clear_inode, put_super, show_options)
- registers FUSE filesystem
o fuse_i.h
- private header file
Requirements
============
The most important difference between orinary filesystems and FUSE is
the fact, that the filesystem data/metadata is provided by a userspace
process run with the privileges of the mount "owner" instead of the
kernel, or some remote entity usually running with elevated
privileges.
The security implication of this is that a non-privileged user must
not be able to use this capability to compromise the system. Obvious
requirements arising from this are:
- mount owner should not be able to get elevated privileges with the
help of the mounted filesystem
- mount owner should not be able to induce undesired behavior in
other users' or the super user's processes
- mount owner should not get illegitimate access to information from
other users' and the super user's processes
These are currently ensured with the following constraints:
1) mount is only allowed to directory or file which the mount owner
can modify without limitation (write access + no sticky bit for
directories)
2) nosuid,nodev mount options are forced
3) any process running with fsuid different from the owner is denied
all access to the filesystem
1) and 2) are ensured by the "fusermount" mount utility which is a
setuid root application doing the actual mount operation.
3) is ensured by a check in the permission() method in kernel
I started thinking about doing 3) in a different way because Christoph
H. made a big deal out of it, saying that FUSE is unacceptable into
mainline in this form.
The suggested use of private namespaces would be OK, but in their
current form have many limitations that make their use impractical (as
discussed in this thread).
Suggested improvements that would address these limitations:
- implement shared subtrees
- allow a process to join an existing namespace (make namespaces
first-class objects)
- implement the namespace creation/joining in a PAM module
With all that in place the check of owner against current->fsuid may
be removed from the FUSE kernel module, without compromising the
security requirements.
Suid programs still interesting questions, since they get access even
to the private namespace causing some information leak (exact
order/timing of filesystem operations performed), giving some
ptrace-like capabilities to unprivileged users. BTW this problem is
not strictly limited to the namespace approach, since suid programs
setting fsuid and accessing users' files will succeed with the current
approach too.
Signed-off-by: Miklos Szeredi <miklos@szeredi.hu>
Signed-off-by: Andrew Morton <akpm@osdl.org>
Signed-off-by: Linus Torvalds <torvalds@osdl.org>
2005-09-09 16:10:26 -04:00
|
|
|
|
|
|
|
/** Minor version number of this interface */
|
|
|
|
#define FUSE_KERNEL_MINOR_VERSION 1
|
|
|
|
|
|
|
|
/** The node ID of the root inode */
|
|
|
|
#define FUSE_ROOT_ID 1
|
|
|
|
|
2005-09-09 16:10:27 -04:00
|
|
|
/** The major number of the fuse character device */
|
|
|
|
#define FUSE_MAJOR 10
|
|
|
|
|
|
|
|
/** The minor number of the fuse character device */
|
|
|
|
#define FUSE_MINOR 229
|
|
|
|
|
[PATCH] FUSE - core
This patch adds FUSE core.
This contains the following files:
o inode.c
- superblock operations (alloc_inode, destroy_inode, read_inode,
clear_inode, put_super, show_options)
- registers FUSE filesystem
o fuse_i.h
- private header file
Requirements
============
The most important difference between orinary filesystems and FUSE is
the fact, that the filesystem data/metadata is provided by a userspace
process run with the privileges of the mount "owner" instead of the
kernel, or some remote entity usually running with elevated
privileges.
The security implication of this is that a non-privileged user must
not be able to use this capability to compromise the system. Obvious
requirements arising from this are:
- mount owner should not be able to get elevated privileges with the
help of the mounted filesystem
- mount owner should not be able to induce undesired behavior in
other users' or the super user's processes
- mount owner should not get illegitimate access to information from
other users' and the super user's processes
These are currently ensured with the following constraints:
1) mount is only allowed to directory or file which the mount owner
can modify without limitation (write access + no sticky bit for
directories)
2) nosuid,nodev mount options are forced
3) any process running with fsuid different from the owner is denied
all access to the filesystem
1) and 2) are ensured by the "fusermount" mount utility which is a
setuid root application doing the actual mount operation.
3) is ensured by a check in the permission() method in kernel
I started thinking about doing 3) in a different way because Christoph
H. made a big deal out of it, saying that FUSE is unacceptable into
mainline in this form.
The suggested use of private namespaces would be OK, but in their
current form have many limitations that make their use impractical (as
discussed in this thread).
Suggested improvements that would address these limitations:
- implement shared subtrees
- allow a process to join an existing namespace (make namespaces
first-class objects)
- implement the namespace creation/joining in a PAM module
With all that in place the check of owner against current->fsuid may
be removed from the FUSE kernel module, without compromising the
security requirements.
Suid programs still interesting questions, since they get access even
to the private namespace causing some information leak (exact
order/timing of filesystem operations performed), giving some
ptrace-like capabilities to unprivileged users. BTW this problem is
not strictly limited to the namespace approach, since suid programs
setting fsuid and accessing users' files will succeed with the current
approach too.
Signed-off-by: Miklos Szeredi <miklos@szeredi.hu>
Signed-off-by: Andrew Morton <akpm@osdl.org>
Signed-off-by: Linus Torvalds <torvalds@osdl.org>
2005-09-09 16:10:26 -04:00
|
|
|
struct fuse_attr {
|
|
|
|
__u64 ino;
|
|
|
|
__u64 size;
|
|
|
|
__u64 blocks;
|
|
|
|
__u64 atime;
|
|
|
|
__u64 mtime;
|
|
|
|
__u64 ctime;
|
|
|
|
__u32 atimensec;
|
|
|
|
__u32 mtimensec;
|
|
|
|
__u32 ctimensec;
|
|
|
|
__u32 mode;
|
|
|
|
__u32 nlink;
|
|
|
|
__u32 uid;
|
|
|
|
__u32 gid;
|
|
|
|
__u32 rdev;
|
|
|
|
};
|
|
|
|
|
2005-09-09 16:10:27 -04:00
|
|
|
enum fuse_opcode {
|
|
|
|
FUSE_INIT = 26
|
|
|
|
};
|
|
|
|
|
|
|
|
/* Conservative buffer size for the client */
|
|
|
|
#define FUSE_MAX_IN 8192
|
|
|
|
|
|
|
|
struct fuse_init_in_out {
|
|
|
|
__u32 major;
|
|
|
|
__u32 minor;
|
|
|
|
};
|
|
|
|
|
|
|
|
struct fuse_in_header {
|
|
|
|
__u32 len;
|
|
|
|
__u32 opcode;
|
|
|
|
__u64 unique;
|
|
|
|
__u64 nodeid;
|
|
|
|
__u32 uid;
|
|
|
|
__u32 gid;
|
|
|
|
__u32 pid;
|
|
|
|
};
|
|
|
|
|
|
|
|
struct fuse_out_header {
|
|
|
|
__u32 len;
|
|
|
|
__s32 error;
|
|
|
|
__u64 unique;
|
|
|
|
};
|
|
|
|
|