09 Jun, 2009
1 commit
-
CUSE enables implementing character devices in userspace. With recent
additions of ioctl and poll support, FUSE already has most of what's
necessary to implement character devices. All CUSE has to do is
bonding all those components - FUSE, chardev and the driver model -
nicely.When client opens /dev/cuse, kernel starts conversation with
CUSE_INIT. The client tells CUSE which device it wants to create. As
the previous patch made fuse_file usable without associated
fuse_inode, CUSE doesn't create super block or inodes. It attaches
fuse_file to cdev file->private_data during open and set ff->fi to
NULL. The rest of the operation is almost identical to FUSE direct IO
case.Each CUSE device has a corresponding directory /sys/class/cuse/DEVNAME
(which is symlink to /sys/devices/virtual/class/DEVNAME if
SYSFS_DEPRECATED is turned off) which hosts "waiting" and "abort"
among other things. Those two files have the same meaning as the FUSE
control files.The only notable lacking feature compared to in-kernel implementation
is mmap support.Signed-off-by: Tejun Heo
Signed-off-by: Miklos Szeredi
26 Jun, 2006
1 commit
-
Add a control filesystem to fuse, replacing the attributes currently exported
through sysfs. An empty directory '/sys/fs/fuse/connections' is still created
in sysfs, and mounting the control filesystem here provides backward
compatibility.Advantages of the control filesystem over the previous solution:
- allows the object directory and the attributes to be owned by the
filesystem owner, hence letting unpriviled users abort the
filesystem connection- does not suffer from module unload race
[akpm@osdl.org: fix this fs for recent dhowells depredations]
[akpm@osdl.org: fix 64-bit printk warnings]
Signed-off-by: Miklos Szeredi
Signed-off-by: Andrew Morton
Signed-off-by: Linus Torvalds
10 Sep, 2005
4 commits
-
This patch adds the file operations of FUSE.
The following operations are added:
o open
o flush
o release
o fsync
o readpage
o commit_writeSigned-off-by: Miklos Szeredi
Signed-off-by: Andrew Morton
Signed-off-by: Linus Torvalds -
This patch adds the read-only filesystem operations of FUSE.
This contains the following files:
o dir.c
- directory, symlink and file-inode operationsThe following operations are added:
o lookup
o getattr
o readlink
o follow_link
o directory open
o readdir
o directory release
o permission
o dentry revalidate
o statfsSigned-off-by: Miklos Szeredi
Signed-off-by: Andrew Morton
Signed-off-by: Linus Torvalds -
This adds the FUSE device handling functions.
This contains the following files:
o dev.c
- fuse device operations (read, write, release, poll)
- registers misc device
- support for sending requests to userspaceSigned-off-by: Miklos Szeredi
Signed-off-by: Adrian Bunk
Signed-off-by: Andrew Morton
Signed-off-by: Linus Torvalds -
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 filesystemo fuse_i.h
- private header fileRequirements
============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 processesThese 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 filesystem1) 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
Signed-off-by: Andrew Morton
Signed-off-by: Linus Torvalds