On Wed, 09 Jan 2008 07:40:12 +0300, Al Boldi said:
But why wouldn't it be possible to do this on the current fs infrastructure,
using just a smart fsck, working incrementally on some sub-dir?
If you have /home/usera, /home/userb, and /home/userc, the vast majority of
fs screw-ups can't be
Hi,
loop.c currently uses the page cache interface to do IO to file backed
devices. This works reasonably well for simple things, like mapping an
iso9660 file for direct mount and other read-only workloads. Writing is
somewhat problematic, as anyone who has really used this feature can
attest to
On Tue 2008-01-08 12:35:09, Miklos Szeredi wrote:
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
Hi,
On Wed, 9 Jan 2008, Nigel Cunningham wrote:
On Tue 2008-01-08 12:35:09, Miklos Szeredi wrote:
For the suspend issue, there are also no easy solutions.
What are the non-easy solutions?
A practical point of view I've seen only fuse rootfs mounts to be a
problem. I remember Ubuntu
Andi Kleen wrote:
Theodore Tso [EMAIL PROTECTED] writes:
Now, there are good reasons for doing periodic checks every N mounts
and after M months. And it has to do with PC class hardware. (Ted's
aphorism: PC class hardware is cr*p).
If these reasons are good ones (some skepticism here)
Hi.
Miklos Szeredi wrote:
On Tue 2008-01-08 12:35:09, Miklos Szeredi wrote:
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
'updatedb no longer works' is not a problem?
I haven't seen any problems with updatedb, and haven't had any bug
reports about it either.
Ok, I don't know much about FUSE. In current version, if user creates
infinite maze and mounts it under ~, updatedb just does not enter it?
It
On Wed, Jan 09 2008, Christoph Hellwig wrote:
On Wed, Jan 09, 2008 at 09:52:32AM +0100, Jens Axboe wrote:
- The file block mappings must not change while loop is using the file.
This means that we have to ensure exclusive access to the file and
this is the bit that is currently missing
On Wed, Jan 09, 2008 at 09:52:32AM +0100, Jens Axboe wrote:
- The file block mappings must not change while loop is using the file.
This means that we have to ensure exclusive access to the file and
this is the bit that is currently missing in the implementation. It
would be nice if we
On Tue, Jan 08, 2008 at 12:35:08PM +0100, Miklos Szeredi wrote:
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
On Wed 2008-01-09 09:47:31, Miklos Szeredi wrote:
On Tue 2008-01-08 12:35:09, Miklos Szeredi wrote:
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
On Wed, 9 Jan 2008 10:43:21 +0100
Jens Axboe [EMAIL PROTECTED] wrote:
On Wed, Jan 09 2008, Christoph Hellwig wrote:
On Wed, Jan 09, 2008 at 09:52:32AM +0100, Jens Axboe wrote:
- The file block mappings must not change while loop is using the
file. This means that we have to ensure
Hi!
AFAIR there were two security vulnerabilities in fuse's history, one
of them an information leak in the kernel module, and the other one an
mtab corruption issue in the fusermount utility. I don't think this
is such a bad track record.
Not bad indeed. But I'd consider 'kill
Valerie Henson wrote:
On Jan 8, 2008 8:40 PM, Al Boldi [EMAIL PROTECTED] wrote:
Rik van Riel wrote:
Al Boldi [EMAIL PROTECTED] wrote:
Has there been some thought about an incremental fsck?
You know, somehow fencing a sub-dir to do an online fsck?
Search for chunkfs
On Tue, Jan 08, 2008 at 12:35:08PM +0100, Miklos Szeredi wrote:
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
On Jan 8 2008 20:08, Miklos Szeredi wrote:
On Tue, 2008-01-08 at 12:35 +0100, Miklos Szeredi wrote:
+static int reserve_user_mount(void)
+{
+ int err = 0;
+
+ spin_lock(vfsmount_lock);
+ if (nr_user_mounts = max_user_mounts !capable(CAP_SYS_ADMIN))
+
On Wed, Jan 09, 2008 at 01:45:09PM +0100, Jan Engelhardt wrote:
On Jan 8 2008 20:08, Miklos Szeredi wrote:
On Tue, 2008-01-08 at 12:35 +0100, Miklos Szeredi wrote:
+static int reserve_user_mount(void)
+{
+ int err = 0;
+
+ spin_lock(vfsmount_lock);
+ if
case EMFILE:
error (mount table full); break;
OK, we could go with EMFILE, but the message should be changed to
something like maximum unprivileged mount count exceeded.
Miklos
-
To unsubscribe from this list: send the line unsubscribe linux-fsdevel in
the body of a message to [EMAIL
I'm not saying fuse is worthless. It is a nice toy for single-user
systems. But I do not think we should be merging allow ordinary users
to mount their own fuse's before issues above are fixed.
I think multi user systems are not all that interesting. And I
suspect very few of them want
Hi!
...this will break with FUSE enabled, right? (Minor security hole by
allowing users to stop c-a-delete, where none existed before?)
Yup (or I don't know, I'm sure there was or is some problem with
ptrace, that could be used to create unkillable processes).
Fuse could actually be
I'm not saying fuse is worthless. It is a nice toy for single-user
systems. But I do not think we should be merging allow ordinary users
to mount their own fuse's before issues above are fixed.
I think multi user systems are not all that interesting. And I
suspect very few of them
On Wed, 9 Jan 2008 14:52:14 +0300
Al Boldi [EMAIL PROTECTED] wrote:
Ok, but let's look at this a bit more opportunistic / optimistic.
You can't play fast and loose with data integrity.
Besides, if we looked at things optimistically, we would conclude
that no fsck will be needed, ever :)
Hello,
On Wed, January 9, 2008 05:39, Tetsuo Handa wrote:
Hello.
Indan Zupancic wrote:
I think you focus too much on your way of enforcing filename/attributes
pairs.
So?
So that you miss alternatives and don't see the bigger picture.
The same can be achieved by creating the device nodes
Jens Axboe [EMAIL PROTECTED] writes:
So how does it work? Instead of punting IO to a thread and passing it
through the page cache, we instead attempt to send the IO directly to the
Great -- something like this was needed for a long time.
- The file block mappings must not change while loop
Here's the latest version of dm-loop, for comparison.
To try it out,
ln -s dmsetup dmlosetup
and supply similar basic parameters to losetup.
(using dmsetup version 1.02.11 or higher)
Alasdair
From: Bryn Reeves [EMAIL PROTECTED]
This implements a loopback target for device mapper allowing a
Quoting Indan Zupancic ([EMAIL PROTECTED]):
Hello,
On Wed, January 9, 2008 05:39, Tetsuo Handa wrote:
Hello.
Indan Zupancic wrote:
I think you focus too much on your way of enforcing filename/attributes
pairs.
So?
So that you miss alternatives and don't see the bigger picture.
On Thu, Jan 10, 2008 at 12:43:19AM +0100, [EMAIL PROTECTED] wrote:
oh, nice to see that this is still alive.
at least i got no crashes and was able to mount and acess more than 300
iso-images with that.
were there fixes/chances since then?
Little has changed for some time - mostly code
On Thu, January 10, 2008 00:08, Serge E. Hallyn wrote:
These emails again are getting really long, but I think the gist of
Indan's suggestion can be concisely summarized:
No worry, I wasn't planning on extending it, I've said what I've to say.
Except...
To confine process P3 to
On Wednesday 09 January 2008 19:52, Jens Axboe wrote:
So how does it work? Instead of punting IO to a thread and passing it
through the page cache, we instead attempt to send the IO directly to the
filesystem block that it maps to.
You told Christoph that just using direct-IO from kernel
The following is a series of patchsets related to Unionfs. This is the
fourth set of patchsets resulting from an lkml review of the entire unionfs
code base, in preparation for a merge into mainline. The most significant
changes here are a few locking/race bugfix related to branch-management.
Add necessary locking to dentry/inode branch-configuration, so we get
consistent values during branch-management actions. In d_revalidate_chain,
-permission, and -create, also lock parent dentry.
Signed-off-by: Erez Zadok [EMAIL PROTECTED]
---
fs/unionfs/commonfops.c |6 ++
Ensure we have lower inodes in prepare/commit_write.
Signed-off-by: Erez Zadok [EMAIL PROTECTED]
---
fs/unionfs/mmap.c | 26 +-
1 files changed, 21 insertions(+), 5 deletions(-)
diff --git a/fs/unionfs/mmap.c b/fs/unionfs/mmap.c
index a0e654b..ad770ac 100644
---
Signed-off-by: Erez Zadok [EMAIL PROTECTED]
---
fs/unionfs/dentry.c |3 ++-
1 files changed, 2 insertions(+), 1 deletions(-)
diff --git a/fs/unionfs/dentry.c b/fs/unionfs/dentry.c
index d969640..cd15243 100644
--- a/fs/unionfs/dentry.c
+++ b/fs/unionfs/dentry.c
@@ -507,9 +507,10 @@ static
CC: Joe Perches [EMAIL PROTECTED]
Signed-off-by: Erez Zadok [EMAIL PROTECTED]
---
fs/unionfs/debug.c | 51 +--
1 files changed, 25 insertions(+), 26 deletions(-)
diff --git a/fs/unionfs/debug.c b/fs/unionfs/debug.c
index 5f1d887..d154c32 100644
Quoting Miklos Szeredi ([EMAIL PROTECTED]):
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
Hello.
Indan Zupancic wrote:
Good point, but I assume they all have at least a directory granularity, and
then
/dev/ can be static and udev and other can have free reign in e.g.
/dev/dynamic/.
Just use subdirs for the dynamic stuff and this granularity problem is, with
slight
36 matches
Mail list logo
