From: Miklos Szeredi [EMAIL PROTECTED]
Declarations go into headers.
Signed-off-by: Miklos Szeredi [EMAIL PROTECTED]
---
Index: linux/fs/super.c
===
--- linux.orig/fs/super.c 2007-04-26 13:08:34.0 +0200
+++ linux/fs
From: Miklos Szeredi [EMAIL PROTECTED]
Define a new fs flag FS_SAFE, which denotes, that unprivileged mounting of
this filesystem may not constitute a security problem.
Since most filesystems haven't been designed with unprivileged mounting in
mind, a thorough audit is needed before setting
From: Miklos Szeredi [EMAIL PROTECTED]
Add sysctl variables for accounting and limiting the number of user
mounts.
The maximum number of user mounts is set to 1024 by default. This
won't in itself enable user mounts, setting a mount to be owned by a
user is first needed
[akpm]
- don't use
From: Miklos Szeredi [EMAIL PROTECTED]
Allow clone_mnt() to return errors other than ENOMEM. This will be used for
returning a different error value when the number of user mounts goes over the
limit.
Fix copy_tree() to return EPERM for unbindable mounts.
Don't propagate further from
From: Miklos Szeredi [EMAIL PROTECTED]
On mount propagation, let the owner of the clone be inherited from the
parent into which it has been propagated. Also if the parent has the
nosuid flag, set this flag for the child as well.
This makes sense for example, when propagation is set up from
From: Miklos Szeredi [EMAIL PROTECTED]
This patchset adds support for keeping mount ownership information in the
kernel, and allow unprivileged mount(2) and umount(2) in certain cases.
The mount owner has the following privileges:
- unmount the owned mount
- create a submount under
From: Miklos Szeredi [EMAIL PROTECTED]
Add a new mount flag nomnt, which denies submounts for the owner.
This would be useful, if we want to support traditional /etc/fstab
based user mounts.
In this case mount(8) would still have to be suid-root, to check the
mountpoint against the user/users
From: Miklos Szeredi [EMAIL PROTECTED]
The owner doesn't need sysadmin capabilities to call umount().
Similar behavior as umount(8) on mounts having user=UID option in /etc/mtab.
The difference is that umount also checks /etc/fstab, presumably to exclude
another mount on the same mountpoint
v4 - v5:
- fold back Andrew's changes
- fold back my update patch:
o use fsuid instead of ruid
o allow forced unpriv. unmounts for safe filesystems
o allow mounting over special files, but not over symlinks
o set nosuid and nodev based on lack of specific capability
- patch
From: Miklos Szeredi [EMAIL PROTECTED]
Use FS_SAFE for fuse fs type, but not for fuseblk.
FUSE was designed from the beginning to be safe for unprivileged users. This
has also been verified in practice over many years. In addition unprivileged
mounts require the parent mount to be owned
From: Miklos Szeredi [EMAIL PROTECTED]
Allow bind mounts to unprivileged users if the following conditions are met:
- mountpoint is not a symlink
- parent mount is owned by the user
- the number of user mounts is below the maximum
Unprivileged mounts imply MS_SETUSER, and will also have
From: Miklos Szeredi [EMAIL PROTECTED]
I get lot's of these on i386:
In file included from include/asm/atomic.h:10,
from include/linux/file.h:9,
from mm/fadvise.c:12:
include/asm/arch/atomic.h: In function ‘atomic_add_unless’:
include/asm/arch/atomic.h:240
From: Miklos Szeredi [EMAIL PROTECTED]
These haven't been fixed for ages. Just make comments out of them.
arch/um/kernel/skas/process.c:181:2: warning: #warning Need to look up
userspace_pid by cpu
arch/um/kernel/skas/process.c:187:2: warning: #warning Need to look up
userspace_pid by cpu
We're having a bit of a disagreement with Christoph Hellwig about the
way FUSE does (or should do) permission checking. Comments (either
way) are appreciated.
Here's my side of the story:
FUSE (filesystem in userspace) is designed to allow mounting an FS by
non-privileged users (it can also be
3) No other user should have access to files under the mount, not
even root[5]
[5] Obviously root cannot be restricted, but accidental access to
private data is still a good idea. E.g. root squashing by NFS servers
has a similar affect.
Could you explain a little more? I
3) No other user should have access to files under the mount, not
even root[5]
[5] Obviously root cannot be restricted, but accidental access to
private data is still a good idea. E.g. root squashing by NFS servers
has a similar affect.
Could you explain a
1) User must not be able to modify files or directories in a way
which he otherwise could not do (e.g. mount a filesystem over
/bin)
2) Suid and device semantics should be disabled within the mount
3) No other user should have access to files under the mount, not
Root squashing is actually a much less obnoxious restriction. It means
that local uid 0 doesn't automatically correspond to remote uid 0.
I don't agree that it's less obnoxious. Root squashing and a
restricted directory (-rwx--) would have exactly the same affect:
root is
I think that would be _much_ nicer implemented as a mount which is
invisible to other users, rather than one which causes the admin's
scripts to spew error messages.
Spew is a strong word. It'll get a single EACCES at the mountpoint.
The same is true for directories not accessible by 'nobody'
Well the sanity check on the server side is always enforced. You
can't trick sftp or ftp to not check permissions. So checking on
the client side too (where the fuse daemon is running) makes no
sense, does it?
That argument doesn't make much sense to me. But we're at the end of
my
Note that NFS checks the permissions on _both_ the client and server,
for a reason.
Does it? If I read the code correctly the client checks credentials
supplied by the server (or cached). But the server does the actual
checking of permissions.
Am I missing something?
Thanks,
Miklos
-
To
With that, the desire for virtual filesystems which cannot be read
by your sysadmin (by accident) is easy to satisfy - and that kind of
mechanism would probably be acceptable to all.
The problem is that this way the responsibility goes to the userspace
program, which can't be
If the user wants to edit a read-only file in a tgz owned by himself,
why can he not _chmod_ the file and _then_ edit it?
That said, I would _usually_ prefer that when I enter a tgz, that I
see all component files having the same uid/gid/permissions as the tgz
file itself - the same as I'd
For 1) your porposal makes sense, however for 2) it's useless, since
now the user doesn't want the hiding.
I realize that the idea _could_ be used to drop 'allow_root' mount
option from the kernel. Since 'allow_root' doesn't add any security
over 'allow_other' it's safe to do it in userspace.
I can accept that usually you are not interested in the stored
uid/gid. But doubt that you want to lose permission information when
you mount a tar file. Zip is a different kettle of fish since that
doesn't contain uid/gid/permissions.
It's not about being not interested.
It's
Indeed, if it can be done with namespaces _and_ mounting on a file
(that file-as-directory concept), _and_ automounting, then you could
cd into your tgz files and others could too :)
There's still that little problem of accessing the tgz file both as a
file and a directory. But yes. Maybe in
And for either version of NFS, if the uid and gid are non-zero, and
the permission bits indicate that an access is permitted, then the
client does not consult the server for permission.
Where's that? I see no such check.
/*
* Trust UNIX mode bits except:
Note that NFS checks the permissions on _both_ the client and server,
for a reason.
Does it? If I read the code correctly the client checks credentials
supplied by the server (or cached). But the server does the actual
checking of permissions.
Am I missing something?
Yes,
There was a thread a few months ago where file-as-directory was
discussed extensively, after Namesys implemented it. That's where the
conversation on detachable mount points originated AFAIR. It will
probably happen at some point.
A nice implemention of it in FUSE could push it along a
Still can't find it :)
Which kernel? Which file?
I'm looking at linux-2.4.30/fs/nfs/dir.c.
Ahh, OK.
nfs_permission() in 2.6 looks quite a bit different. And permission
bits are not used if -access() is available.
Miklos
-
To unsubscribe from this list: send the line unsubscribe
There are uses for both. For example today I was updating the tar ball
which is used to create the var file system for a new chroot. I certainly
want to see corretly setup owner/permissions when I look into that tar
ball using a FUSE fs...
If I'm updating a var filesystem for a new
Aren't there some assumptions in VFS that currently make this
impossible?
I believe it's OK with VFS, but applications would be confused to death.
Well, there really is one issue -- dentries have exactly one parent, so
what do you do when opening a file with hardlinks as a directory? (In
Look up the rather large linux-kernel linux-fsdevel thread silent
semantic changes with reiser4 and it's followup threads, from last
year.
Wow, it's 700+ messages. I got through the first 40, and already feel
dizzy :)
It's already been tried. You will also find sensible ideas on what
I have a little project to imlement a userloop filesystem, which
works just like mount -o loop, but you don't need root privs. This
is really simple to do with FUSE and UML.
That would be a nice way to implement those rarely used old
filesystems that aren't really needed in the kernel
Yet, the results from stat() don't distinguish the number spaces,
and ls doesn't map the numbers to names properly in the wrong
space.
Well you can use ls -n. It's up to the tools to present the
information you want in the way you want it. If a tool can't do that,
tough, but
1) Only allow mount over a directory for which the user has write
access (and is not sticky)
2) Use nosuid,nodev mount options
[ parts deleted ]
Do these solve all the security concerns with unprivileged mounts, or
are there other barriers/concerns? Should there be
This program works similarly to mount -o loop, but the filesystem
runs in userspace, making it possible for non-root users to safely
loopback mount filesystem images.
It works by starting a UML (User Mode Linux) instance, mounting the
image in there, and exporting the resulting data through FUSE.
I think you shouldn't help the admins by creating shoes with target marks.
Allowing user mounts with no* should be allways ok (no config needed
besides the ulimit), and mounting specified files to defined locations
is allready supported by fstab.
I tend to agree. It should be obvious
Likely because its a chroot vulnerability.
It allows a process to obtain a reference to the root vfsmount that
doesn't have chroot checks performed on it.
Consider the following pseudo example:
[...]
if main is run within a chroot where it's / is on the same vfsmount as
it's .., then
/** The major number of the fuse character device */
-#define FUSE_MAJOR 10
+#define FUSE_MAJOR MISC_MAJOR
OK, this makes some sense.
/** The minor number of the fuse character device */
-#define FUSE_MINOR 229
+#define FUSE_MINOR MISC_DYNAMIC_MINOR
Why?
FUSE has an allocated fix
/** The minor number of the fuse character device */
-#define FUSE_MINOR 229
+#define FUSE_MINOR MISC_DYNAMIC_MINOR
FUSE has an allocated fix minor. Dynamic minor is much harder to
handle with legacy /dev (not udev).
How many users of 2.6.13 and up really do not have/run udev?
I get the following build failure on 2.6.13-rc3-mm1. It builds fine
on 2.6.13-rc3.
Can anybody help fixing it?
Thanks,
Miklos
/usr/src/quilt/linux$ make ARCH=um V=1
if test ! /usr/src/quilt/linux -ef /usr/src/quilt/linux; then \
/bin/sh /usr/src/quilt/linux/scripts/mkmakefile \
Thanks for the writeup, it helps to understand things a bit better.
However I still don't understand a few things:
Section 1. mount:
to begin with we have a the following mount tree
root
/ / \ \ \
/ t1 t2 \ \
git-kbuild.patch
This breaks building of external modules:
make -C /usr/src/linux-2.6.13-rc3-mm2 M=/home/miko/fuse/kernel modules
make[1]: Entering directory `/usr/src/linux-2.6.13-rc3-mm2'
WARNING: Symbol version dump /usr/src/linux-2.6.13-rc3-mm2/Module.symvers
@@ -54,7 +55,7 @@ static inline unsigned long hash(struct
struct vfsmount *alloc_vfsmnt(const char *name)
{
- struct vfsmount *mnt = kmem_cache_alloc(mnt_cache, GFP_KERNEL);
+ struct vfsmount *mnt = kmem_cache_alloc(mnt_cache, GFP_KERNEL);
if (mnt) {
+static int do_make_shared(struct vfsmount *mnt)
+{
+ int err=0;
+ struct vfspnode *old_pnode = NULL;
+ /*
+ * if the mount is already a slave mount,
+ * allocate a new pnode and make it
+ * a slave pnode of the original pnode.
+ */
+ if
This is an example, where having struct pnode just complicates things.
If there was no struct pnode, this function would be just one line:
setting the shared flag.
So your comment is mostly about getting rid of pnode and distributing
the pnode functionality in the vfsmount structure.
Yes,
Thanks for the report. I had overlooked this usage when modifying this
part of kbuild.
The following fix it - and work in the following test setups:
make
make O=
make M=
make O= M=
Yes, it works now.
Thanks,
Miklos
-
To unsubscribe from this list: send the line unsubscribe linux-kernel
Actually, the right question is how is fuse better than coda. I've
asked that before; unlike nfs, userspace filesystems implemented with
coda actually *work*, but do not provide partial-file writes.
You answered your own question.
I did talk to Jan Harkes about the file I/O issue before
It is important because on UNIX, root rules on local filesystems.
I dont't like the idea of root not being able to run find -xdev
anymore for administrative tasks, just because something got hidden
by accident or just for fun by a user. It's not about malicious
users who want to hide data:
[CC restored]
Okay, I just wanted to mention CODA. Modifying CODA is probably still
better than modifying NFS (as akpm suggested at one point).
Definitely.
Here are some numbers on the size these filesystems as in current -mm
('wc fs/${fs}/* include/linux/${fs}*')
nfs: 25495
9p:6102
solving it properly refers to hardening the leaf node constraint
against circumvention I assume. Suppose there's a script for doing simple
on-line backups using find. Now explain to the user why he lost his
data due to a backup script geting EACCES on a non-leaf FUSE mount.
I see your point.
I see your point. But then this is really not a security issue, but
an are you sure you want to format C: style protection for the
user's own sake. Adding a mount option (checked by the library) for
this would be fine. E.g. with mount_nonempty it would not refuse to
mount on a
- Anything which you think needs to go into 2.6.13, please let me know.
FUSE?
I don't see any advantage of holding it off any more.
I feel the slightest of distrust towards the usefulness or quality of
FUSE. Anyway if the users aren't interested enough to complain about
inclusion, it's not
I'm inclined to just give up on the permissions thing - if someone comes up
with something better then fine.
But I do wonder whether v9fs would be a better place to be concentrating
the development effort.
v9fs is a network filesystem. And it's a network filesystem that's
not even very
This patch adds the shared/private/slave support for VFS trees.
[...]
-struct vfsmount *lookup_mnt(struct vfsmount *mnt, struct dentry *dentry)
+struct vfsmount *lookup_mnt(struct vfsmount *mnt, struct dentry *dentry,
struct dentry *root)
{
How about changing it to inline and calling it
+ * recursively change the type of the mountpoint.
+ */
+static int do_change_type(struct nameidata *nd, int flag)
+{
+ struct vfsmount *m, *mnt;
+ struct vfspnode *old_pnode = NULL;
+ int err;
+
+ if (!(flag MS_SHARED) !(flag MS_PRIVATE)
+ !(flag
The reason why I implemented that way, is to less confuse the user and
provide more flexibility. With my implementation, we have the ability
to share any part of the tree, without bothering if it is a mountpoint
or not. The side effect of this operation is, it ends up creating
a vfsmount if
Forget to mention, we are checking linux 2.6. It appears to us
that mmap doesnt' work for FUSE in linux 2.6.
IIRC, the reason mmap doesn't work on FUSE is because when it
dirties pages they cannot be flushed reliably, because writing them
out involves calling a userspace process which
with a per-mount RW semaphore which is acquired for
read in request_end() and for write in fuse_put_super().
(*) requests for which the original requester thread isn't waiting any
more
Signed-off-by: Miklos Szeredi [EMAIL PROTECTED]
dev.c| 33 ++---
fuse_i.h | 15
Hi Andrew!
In the prevous fix (fix busy inodes after unmount) I forgot to protect
against concurrent modification of the background list. This patch
adds the necessary locking.
Next time I'll think before sending.
Signed-off-by: Miklos Szeredi [EMAIL PROTECTED]
diff -rup linux-2.6.12-rc1-mm1
Hi Andrew!
This patch fixes an inode leak in fuse_get_dentry(). With libfuse
this practically never triggers, but a DoS exploit could be written.
Please Apply.
Thanks,
Miklos
Signed-off-by: Miklos Szeredi [EMAIL PROTECTED]
diff -rup linux-2.6.11-mm1/fs/fuse/inode.c linux-fuse/fs/fuse/inode.c
-by: Miklos Szeredi [EMAIL PROTECTED]
diff -rup linux-2.6.11-mm1/fs/fuse/dev.c linux-fuse/fs/fuse/dev.c
--- linux-2.6.11-mm1/fs/fuse/dev.c 2005-03-04 23:26:59.0 +0100
+++ linux-fuse/fs/fuse/dev.c2005-03-04 23:32:36.0 +0100
@@ -121,12 +121,11 @@ struct fuse_req
Hi Andrew!
This patch adds generic_file_llseek to fuse_file_operations and
fuse_dir_operations, replacing the implicit default_llseek.
Please Apply.
Thanks,
Miklos
Signed-off-by: Miklos Szeredi [EMAIL PROTECTED]
diff -rup linux-2.6.11-mm1/fs/fuse/dir.c linux-fuse/fs/fuse/dir.c
--- linux
The attached patch replaces backing_dev_info::memory_backed with
capabilitied bitmap. The capabilities available include:
Wouldn't it be better to reverse the meaning of BDI_CAP_ACCOUNT_DIRTY
and BDI_CAP_WRITEBACK_DIRTY (BDI_CAP_NO_ACCOUNT_DIRTY...)? That way
out of tree filesystems that
Wouldn't it be better to reverse the meaning of BDI_CAP_ACCOUNT_DIRTY
and BDI_CAP_WRITEBACK_DIRTY (BDI_CAP_NO_ACCOUNT_DIRTY...)? That way
out of tree filesystems that implicitly zero bdi-memory_backed
wouldn't _silently_ break. E.g. fuse does this, though it would not
actually break
Sorry, yes. Obvious. Ugh. Andrew Morton suggested flipping the logic, and
although it was in conjunction with turning the concepts into bitfields, it
still stands here.
OK, obviously Andrew has the final word in this. I just suggested
that it might be safer to have the logic flipped back.
The group I work in has been experimenting with GFS and Lustre, and I did
some NBD/ENBD experimentation on my own, described at
http://dcs.nac.uci.edu/~strombrg/nbd.html
My question is, what is the current status of huge filesystems - IE,
filesystems that exceed 2 terabytes, and hopefully
This removes check for non-null inode before calling iput(), and uses
iov_length() to calculate number of bytes in iovec.
Signed-off-by: Miklos Szeredi [EMAIL PROTECTED]
dev.c | 30 +-
1 files changed, 9 insertions(+), 21 deletions(-)
diff -ru linux-2.6.12-rc1-mm2
This adds lots of documentation to dev.c. This file is raised from
least documented to most documented status.
Signed-off-by: Miklos Szeredi [EMAIL PROTECTED]
dev.c | 246 ++
1 files changed, 232 insertions(+), 14 deletions
This adds lots of documentation to dev.c. This file is raised from
least documented to most documented status.
Signed-off-by: Miklos Szeredi [EMAIL PROTECTED]
[ . . . ]
Put such a big dicumentation to the documentation folder not in the code
This adds lots of documentation for the userspace - kernel interface.
Signed-off-by: Miklos Szeredi [EMAIL PROTECTED]
Documentation/filesystems/fuse.txt | 130 +
fs/fuse/dev.c | 114
2 files changed, 230
the
readdir interface more flexible
3/3 - Change ABI major version from 5 to 6, and check if userspace
supports the new interface
Signed-off-by: Miklos Szeredi [EMAIL PROTECTED]
-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL
Add padding to structures to make sizes the same on 32bit and 64bit
archs. Initial testing and test machine generously provided by Franco
Broi.
Signed-off-by: Miklos Szeredi [EMAIL PROTECTED]
diff -rup linux-2.6.12-rc1-mm4/include/linux/fuse.h
linux-fuse/include/linux/fuse.h
--- linux-2.6.12
This patch adds an offset field to fuse_dirent structure. This will
give userspace filesystems more flexibility in implementing a readdir
method.
Signed-off-by: Miklos Szeredi [EMAIL PROTECTED]
diff -rup linux-2.6.12-rc1-mm4/fs/fuse/dir.c linux-fuse/fs/fuse/dir.c
--- linux-2.6.12-rc1-mm4/fs
Change ABI major version from 5 to 6, and check if userspace supports
the new interface. If the version in INIT reply doesn't match the
current one, return ECONNREFUSED error on all operations.
Signed-off-by: Miklos Szeredi [EMAIL PROTECTED]
diff -rup linux-2.6.12-rc1-mm4/fs/fuse/dev.c linux
This patch fixes a couple of warnings when compiling on the x86_64
architecture.
Signed-off-by: Miklos Szeredi [EMAIL PROTECTED]
diff -rup linux-2.6.12-rc1-mm4/fs/fuse/file.c linux-fuse/fs/fuse/file.c
--- linux-2.6.12-rc1-mm4/fs/fuse/file.c 2005-03-31 21:52:18.0 +0200
+++ linux-fuse/fs
This patch adds a new FSYNCDIR request, which is sent when fsync is
called on directories. This operation is available in libfuse
2.3-pre1 or greater.
Signed-off-by: Miklos Szeredi [EMAIL PROTECTED]
diff -rup linux-2.6.12-rc1-mm4/fs/fuse/dir.c linux-fuse/fs/fuse/dir.c
--- linux-2.6.12-rc1-mm4
(please reply to all, lkml and akpm restored in CC)
Add padding to structures to make sizes the same on 32bit and 64bit
archs. Initial testing and test machine generously provided by Franco
Broi.
__attribute__((aligned(8))) ?
I'll try that.
Thanks,
Miklos
-
To unsubscribe from this
Andrew,
do I believe correctly that you do automatic builds of -mm for lots of
architectures? If yes, is there some place where the output is
available? This would be useful for fixing warnings.
Thanks,
Miklos
-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body
do I believe correctly that you do automatic builds of -mm for lots of
architectures? If yes, is there some place where the output is
available? This would be useful for fixing warnings.
The OSDL PLM tool also does automated builds of all -linus
and -mm releases. 2.6.12-rc1-mm4
This patch correctly sets f_pos in readdir. The offset passed from
userspace is now the offset of the next entry. Needs at least libfuse
2.3-pre2 to work properly.
Zero lengh filenames are also disallowed.
Signed-off-by: Miklos Szeredi [EMAIL PROTECTED]
diff -rup linux-2.6.12-rc1-mm4/fs/fuse
Hi Andrew!
Do you have any objections to merging FUSE in mainline kernel?
It's been in -mm for the 2.6.11 cycle, and the same code was released
a month ago as FUSE-2.2. So it should have received a fair amount of
testing, with no problems found so far.
The one originally merged into -mm
Do you have any objections to merging FUSE in mainline kernel?
It's been in -mm for the 2.6.11 cycle, and the same code was released
a month ago as FUSE-2.2. So it should have received a fair amount of
testing, with no problems found so far.
The one originally merged into -mm
fuse-transfer-readdir-data-through-device.patch
fuse: transfer readdir data through device
It is great that this is fixed, don't remove it, but it does require the fuse
libs to be updated at the same time, or opening dirs for listings will break
like this:
open(.,
Andrew,
This patch makes fuse_fill_super() return correct error value in case
of OOM.
Please apply.
Thanks,
Miklos
Signed-off-by: Miklos Szeredi [EMAIL PROTECTED]
diff -rup linux-2.6.11-rc2-mm1/fs/fuse/inode.c linux-fuse/fs/fuse/inode.c
--- linux-2.6.11-rc2-mm1/fs/fuse/inode.c2005-01
Andrew,
This patch fixes a bug in link, where the wrong inode number was
passed to userspace as the link source.
Needs update to fuse library to 2.2-pre6 as well.
Please apply.
Thanks,
Miklos
Signed-off-by: Miklos Szeredi [EMAIL PROTECTED]
diff -rup linux-2.6.11-rc2-mm1/fs/fuse/dir.c linux
As I personally like for my ls to keep on working, and I assume
others will, too, I would appreciate it if you could add a
warning to your announcements the following one or two weeks or
so, so that people can remove this patch if they don't want to
update their libs.
By any chance
,
Miklos
Signed-off-by: Miklos Szeredi [EMAIL PROTECTED]
diff -rup linux-2.6.11-rc2-mm2/fs/fuse/dev.c linux-fuse/fs/fuse/dev.c
--- linux-2.6.11-rc2-mm2/fs/fuse/dev.c 2005-01-30 21:40:53.0 +0100
+++ linux-fuse/fs/fuse/dev.c2005-02-02 12:44:26.0 +0100
@@ -233,7 +233,7 @@ static void
FUSE version 2.2 is out there:
http://sourceforge.net/project/showfiles.php?group_id=121684package_id=132802release_id=301878
This can be used standalone or with recent -mm kernels (with the
exception of -rc2-mm2).
Most notable changes since 2.1:
- Added file handle parameter to
Some things I'd like to see (as I am currently using the KIO
equivalent) implemented as FUSE fs:
- fish, virtual file access over ssh
This is already available here:
http://sourceforge.net/projects/fuse
You need to dowload fuse-2.2-pre3 and sshfs-1.0. It should work on
any kernel including
Sorry about the missing quotes. It should read:
You wrote:
Some things I'd like to see (as I am currently using the KIO
equivalent) implemented as FUSE fs:
- fish, virtual file access over ssh
This is already available here:
http://sourceforge.net/projects/fuse
You need to dowload
When the root of a mount is a bad inode, it can't be unmounted.
Comment above bad_follow_link is also out of sync with code. What
about just removing the follow_link method from bad_inode_ops
(untested patch attached)?
Same problem exists on 2.4.
Miklos
--- linux-2.6.10/fs/bad_inode.c.orig
Thanks Adrian,
The patch below makes two needlessly global functions static.
Signed-off-by: Adrian Bunk [EMAIL PROTECTED]
Signed-off-by: Miklos Szeredi [EMAIL PROTECTED]
--- linux-2.6.11-rc1-mm1-full/fs/fuse/dev.c.old 2005-01-16 05:56:22.0
+0100
+++ linux-2.6.11-rc1-mm1-full/fs/fuse
inode bad (NFS, SMBFS, FUSE, etc...).
Signed-off-by: Miklos Szeredi [EMAIL PROTECTED]
--- linux-2.6.10/fs/bad_inode.c.orig2005-01-19 21:48:24.0 +0100
+++ linux-2.6.10/fs/bad_inode.c 2005-01-19 22:07:56.0 +0100
@@ -15,17 +15,6 @@
#include linux/smp_lock.h
#include linux
and implementation exactly maching the respective
file operations (OPEN, READ, RELEASE).
This simplifies the directory reading code. Also disk space is not
necessary, which can be important in embedded systems.
Please apply.
Thanks,
Miklos
Signed-off-by: Miklos Szeredi [EMAIL PROTECTED]
diff -ru linux-2.6.11
This patch fixes a problem when a inode which is the root of a mount
becomes bad (make_bad_inode()). In this case follow_link will return
-EIO, so the name resolution fails, and umount won't work. The
solution is just to remove the follow_link method from bad_inode_ops.
Any filesystem
Andrew,
This patch makes llseek behave properly on the FUSE device
Thanks,
Miklos
Signed-off-by: Miklos Szeredi [EMAIL PROTECTED]
diff -rup linux-2.6.11-rc1-mm2/fs/fuse/dev.c linux-fuse/fs/fuse/dev.c
--- linux-2.6.11-rc1-mm2/fs/fuse/dev.c 2005-01-20 09:30:15.0 +0100
+++ linux-fuse/fs
make_bad_inode() to
mark an existing inode bad (NFS, SMBFS, FUSE, etc...).
Signed-off-by: Miklos Szeredi [EMAIL PROTECTED]
--- linux-2.6.10/fs/bad_inode.c.orig2005-01-19 21:48:24.0 +0100
+++ linux-2.6.10/fs/bad_inode.c 2005-01-19 22:07:56.0 +0100
@@ -15,17 +15,6 @@
#include linux
Al, your are the co-maintainer of audit, right? Can you please apply
these patches as Eric is on vaction.
Thanks,
Miklos
From: Miklos Szeredi mszer...@suse.cz
Don't do free_chunk() after fsnotify_add_mark(). That one does a delayed unref
via the destroy list and this results in use-after
501 - 600 of 5429 matches
Mail list logo