On Tue, Jan 15, 2008 at 08:36:46PM +0800, Fengguang Wu wrote:
Redirtied inodes could be seen in really fast writes.
They should really be synced as soon as possible.
redirty_tail() could delay the inode for up to 30s.
Kill the delay by using requeue_io() instead.
That's actually bad for
Hi,
On Tue, 15 Jan 2008, Christoph Hellwig wrote:
Something like the loop above is not going to go in for sure. Once we
get rid of the sb-s_files we can put the list_head in struct file to
new use eventually if we don't want to get rid of it. E.g. and
per-inode list would be much better
Why not nosubmnt?
Why not indeed. Maybe I should try to use my brain sometime.
Well it really should have 'user' or 'unpriv' in the name
somewhere. 'nosubmnt' is more confusing than 'nomnt' because
it no submounts really sounds like a reasonable thing in
itself...
I slept on it,
On Tuesday 15 January 2008, Chris Mason wrote:
Hello everyone,
Btrfs v0.10 is now available for download from:
It does not even compile for me, tested with 2.6.24-rc{7,8}. I will look at
that later.
fs/built-in.o: In function `btrfs_xattr_set_acl':
acl.c:(.text+0x68f33): undefined reference
Hi!
Along with this effort, could you let me know if the world actually
cares about online fsck?
I'm not the world's spokeperson (yet ;-).
Now we know how to do it I think, but is it
worth the effort.
ext3's lets fsck on every 20 mounts is good idea, but it can be
annoying when
From: Miklos Szeredi [EMAIL PROTECTED]
For safe filesystems allow unprivileged mounting and forced
unmounting.
A filesystem type is considered safe, if mounting it by an
unprivileged user may not cause a security problem. This is somewhat
subjective, so setting this property is left to
From: Miklos Szeredi [EMAIL PROTECTED]
Don't require the user_id= and group_id= options for unprivileged mounts,
but if they are present, verify them for sanity.
Disallow the allow_other option for unprivileged mounts.
FUSE was designed from the beginning to be safe for unprivileged
users.
From: Miklos Szeredi [EMAIL PROTECTED]
Add the following:
/proc/sys/fs/types/${FS_TYPE}/usermount_safe
Signed-off-by: Miklos Szeredi [EMAIL PROTECTED]
---
Index: linux/fs/filesystems.c
===
--- linux.orig/fs/filesystems.c
From: Miklos Szeredi [EMAIL PROTECTED]
Add a new mount flag nosubmnt, 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]
On mount propagation, let the owner of the clone be inherited from the
parent into which it has been propagated.
If the parent has the nosuid flag, set this flag for the child as
well. This is needed for the suid-less namespace (use case #2 in the
first
Thanks to everyone for the comments on the previous submission.
Christoph, could you please look through the patches if they are
acceptable from the VFS point of view?
Thanks,
Miklos
v6 - v7:
- add '/proc/sys/fs/types/type/usermount_safe' tunable (new patch)
- do not make FUSE safe by
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.
Signed-off-by: Miklos Szeredi [EMAIL
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 the
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]
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]
This is an experimental patch for supporing unprivileged mounts and
umounts. The following features are added:
1) If mount/umount are suid, first try without privileges.
This is done by forking, dropping privileges in child, and redirecting
stderr to
Util-linux-ng 2.13.1 Release Notes
==
Fixed security issues:
-
CVE-2007-5191 - mount(8) doesn't drop privileges properly when
calling helpers
Changelog:
-
For more details see ChangeLog files at:
Quoting Kentaro Takeda ([EMAIL PROTECTED]):
Hello.
Serge E. Hallyn wrote:
I must say I personally prefer the apparmor approach.
No problem.
But I'd recommend
you get together and get this piece pushed on its own, whichever version
you can agree on.
TOMOYO can use AppArmor's patch.
On Wed, Jan 16, 2008 at 08:43:25AM +1100, David Chinner wrote:
ext3 is not the only filesystem that will have trouble due to
volatile write caches. We see problems often enough with XFS
due to volatile write caches that it's in our FAQ:
In fact it will hit every filesystem. A write-back cache
ons, 16 01 2008 kl. 11:02 +0100, skrev Christian Hesse:
On Tuesday 15 January 2008, Chris Mason wrote:
Hello everyone,
Btrfs v0.10 is now available for download from:
It does not even compile for me, tested with 2.6.24-rc{7,8}. I will look at
that later.
fs/built-in.o: In function
On Wednesday 16 January 2008, Miklos Szeredi wrote:
This is an experimental patch for supporing unprivileged mounts and
umounts. The following features are added:
same feedback as last time ... the cap stuff needs to be made optional and
proper header checks added to configure ...
1) If
This is an experimental patch for supporing unprivileged mounts and
umounts. The following features are added:
same feedback as last time ... the cap stuff needs to be made optional and
proper header checks added to configure ...
Later, sure. For now, I'm concentrating on the actual
On Jan 16, 2008 3:49 AM, Pavel Machek [EMAIL PROTECTED] wrote:
ext3's lets fsck on every 20 mounts is good idea, but it can be
annoying when developing. Having option to fsck while filesystem is
online takes that annoyance away.
I'm sure everyone on cc: knows this, but for the record you can
Alan Cox wrote:
Writeback cache on disk in iteself is not bad, it only gets bad if the
disk is not engineered to save all its dirty cache on power loss,
using the disk motor as a generator or alternatively a small battery.
It would be awfully nice to know which brands fail here, if any,
In message [EMAIL PROTECTED], Michael Halcrow writes:
On Thu, Jan 10, 2008 at 10:57:46AM -0500, Erez Zadok wrote:
[...]
Would the inclusion of Unionfs in mainline really slow down or damage
the union mount effort? If not, then I think the pragmatic approach
would be to make it available in
The reason, why this patch was dug up, is that if the bdi-sysfs patch
is going to use device numbers to identify BDIs, then there should be
a way for the user to map the device number into mount(s).
But it's useful regardless of the bdi-sysfs patch.
Can this be added to -mm?
In theory it could
On Wed, 16 Jan 2008 23:12:31 +0100
Miklos Szeredi [EMAIL PROTECTED] wrote:
The reason, why this patch was dug up, is that if the bdi-sysfs patch
is going to use device numbers to identify BDIs, then there should be
a way for the user to map the device number into mount(s).
But it's useful
The reason, why this patch was dug up, is that if the bdi-sysfs patch
is going to use device numbers to identify BDIs, then there should be
a way for the user to map the device number into mount(s).
But it's useful regardless of the bdi-sysfs patch.
Don't know what that is.
On Wed, Jan 16, 2008 at 02:30:51PM -0800, Andrew Morton wrote:
On Wed, 16 Jan 2008 23:12:31 +0100
Miklos Szeredi [EMAIL PROTECTED] wrote:
In theory it could break userspace, but I think it's very unlikely to
do so, because stuff is added only at the end of the lines, and
because most
On Jan 17 2008 00:43, Karel Zak wrote:
Seems like a plain bad idea to me. There will be any number of home-made
/proc/mounts parsers and we don't know what they do.
So, let's use /proc/mounts_v2 ;-)
Was not it like don't use /proc for new things?
-
To unsubscribe from this list: send the
On Thu, 17 Jan 2008 00:58:06 +0100 (CET) Jan Engelhardt [EMAIL PROTECTED]
wrote:
On Jan 17 2008 00:43, Karel Zak wrote:
Seems like a plain bad idea to me. There will be any number of home-made
/proc/mounts parsers and we don't know what they do.
So, let's use /proc/mounts_v2 ;-)
On Thursday January 17, [EMAIL PROTECTED] wrote:
On Jan 17 2008 00:43, Karel Zak wrote:
Seems like a plain bad idea to me. There will be any number of home-made
/proc/mounts parsers and we don't know what they do.
So, let's use /proc/mounts_v2 ;-)
Was not it like don't use /proc
On Jan 17 2008 11:33, Neil Brown wrote:
On Thursday January 17, [EMAIL PROTECTED] wrote:
On Jan 17 2008 00:43, Karel Zak wrote:
Seems like a plain bad idea to me. There will be any number of home-made
/proc/mounts parsers and we don't know what they do.
So, let's use
Andrew Morton wrote:
Seems like a plain bad idea to me. There will be any number of home-made
/proc/mounts parsers and we don't know what they do.
There is a lot of precedent for adding fields at the end. Since the
last fields in current /proc/*/mounts are dummy fields anyway, it
doesn't
On Wed, Jan 16, 2008 at 11:12:31PM +0100, Miklos Szeredi wrote:
The alternative (and completely safe) solution is to add another file
to proc. Me no likey.
Since we need saner layout, I would strongly suggest exactly that.
major:minor -- is the major minor number of the device hosting the
On Wed, Jan 16, 2008 at 04:09:30PM -0800, Andrew Morton wrote:
On Thu, 17 Jan 2008 00:58:06 +0100 (CET) Jan Engelhardt [EMAIL PROTECTED]
wrote:
On Jan 17 2008 00:43, Karel Zak wrote:
Seems like a plain bad idea to me. There will be any number of home-made
/proc/mounts parsers
On Wed, Jan 16, 2008 at 07:13:07PM +1100, David Chinner wrote:
On Tue, Jan 15, 2008 at 08:36:46PM +0800, Fengguang Wu wrote:
Redirtied inodes could be seen in really fast writes.
They should really be synced as soon as possible.
redirty_tail() could delay the inode for up to 30s.
Kill
Serge:
Right, but one will be preferred by the community - and while I have my
own preference, I wouldn't put too much faith on that, rather talk with
the apparmor folks, look over the lkml logs for previous submissions,
and then decide.
Thanks for your advice.
We got the same advice from
After grep for locking-related things:
* lock_parent(): who said that you won't get dentry moved
before managing to grab i_mutex on parent? While we are at it,
who said that you won't get dentry moved between fetching d_parent
and doing dget()? In that case parent could've been _freed_
In message [EMAIL PROTECTED], Al Viro writes:
After grep for locking-related things:
[...]
Thanks. I'll start looking at these issues asap.
Erez.
-
To unsubscribe from this list: send the line unsubscribe linux-fsdevel in
the body of a message to [EMAIL PROTECTED]
More majordomo info at
On Jan 15, 2008 22:05 -0500, Rik van Riel wrote:
With a filesystem that is compartmentalized and checksums metadata,
I believe that an online fsck is absolutely worth having.
Instead of the filesystem resorting to mounting the whole volume
read-only on certain errors, part of the filesystem
41 matches
Mail list logo
