(cutting out lists from CC)
Your patch is changing the API in a very unsafe way, since there will
be no error or warning on an unconverted fs. And that could lead to
security holes.
If we would rename the setattr method to setattr_new as well as
changing it's behavior,
There's another way to deal with this in NFS and fuse, without having
to change the API:
- remove suid/sgid bits from i_mode, when refreshing the inode attributes
- store the removed bits (or the original mode) in the fs' inode strucure
- in -getattr() restore the original mode into the
There's another way to deal with this in NFS and fuse, without having
to change the API:
- remove suid/sgid bits from i_mode, when refreshing the inode attributes
- store the removed bits (or the original mode) in the fs' inode strucure
- in -getattr() restore the original mode into the
On Tue, 07 Aug 2007 08:00:40 +0200
Miklos Szeredi [EMAIL PROTECTED] wrote:
(cutting out lists from CC)
Your patch is changing the API in a very unsafe way, since there will
be no error or warning on an unconverted fs. And that could lead to
security holes.
If we
On the other hand, the filesystem writers here are declaring their own
setattr operation. Is it unreasonable for them to take responsibility
for handling this too?
We have about half of all the in-tree filesystems declaring
-setattr(), and out of those only two that we know would use this.
On Sun, Aug 05 2007, Daniel Phillips wrote:
A simple way to solve the stable accounting field issue is to add a new
pointer to struct bio that is owned by the top level submitter
(normally generic_make_request but not always) and is not affected by
any recursive resubmission. Then getting
On Tuesday 07 August 2007 05:05, Jens Axboe wrote:
On Sun, Aug 05 2007, Daniel Phillips wrote:
A simple way to solve the stable accounting field issue is to add a
new pointer to struct bio that is owned by the top level submitter
(normally generic_make_request but not always) and is not
The README file in the cramfs subdirectory says:
All data is currently in host-endian format; neither mkcramfs nor the
kernel ever do swabbing.
If somebody tries to mount a cramfs with the wrong endianess,
cramfs only complains about a wrong magic but doesn't inform
the user that only the
+void attr_kill_to_mode(struct inode *inode, struct iattr *attr)
This function badly needs a kerneldoc description. Also I can't say
I like the name a lot, but without a clearly better idea I should
probably not complain :)
We should at least add a generic_ prefix to indicate it's a generic
On Tue, Aug 07 2007, Daniel Phillips wrote:
On Tuesday 07 August 2007 05:05, Jens Axboe wrote:
On Sun, Aug 05 2007, Daniel Phillips wrote:
A simple way to solve the stable accounting field issue is to add a
new pointer to struct bio that is owned by the top level submitter
(normally
On Mon, 2007-08-06 at 09:54 -0400, Jeff Layton wrote:
Signed-off-by: Jeff Layton [EMAIL PROTECTED]
Acked-by: Dave Kleikamp [EMAIL PROTECTED]
---
fs/jfs/acl.c |2 ++
1 files changed, 2 insertions(+), 0 deletions(-)
diff --git a/fs/jfs/acl.c b/fs/jfs/acl.c
index 4d84bdc..34ca314 100644
On Tue, 7 Aug 2007 21:49:09 +0100
Christoph Hellwig [EMAIL PROTECTED] wrote:
First thanks a lot for doing this work, it's been long needed.
Second please don't send out that many patches. We encourage people
to split things into small patches when the changes are logially
separated. Which
On Tue, 7 Aug 2007 21:51:49 +0100
Christoph Hellwig [EMAIL PROTECTED] wrote:
+void attr_kill_to_mode(struct inode *inode, struct iattr *attr)
This function badly needs a kerneldoc description. Also I can't say
I like the name a lot, but without a clearly better idea I should
probably not
On Mon, 6 Aug 2007 09:54:03 -0400
Jeff Layton [EMAIL PROTECTED] wrote:
Apologies for the resend, but the original sending had the date in the
email header and it caused some of these to bounce...
( Please consider trimming the Cc list if discussing some aspect of this
that doesn't concern
On Tue, 2007-08-07 at 17:15 -0700, Andrew Morton wrote:
Is there any way in which we can prevent these problems? Say
The problem here is that we occasionally DO need to add new flags, and
yes, they MAY be security related. The whole reason why we're now having
to change the semantics of
On Tue, 07 Aug 2007 20:45:34 -0400
Trond Myklebust [EMAIL PROTECTED] wrote:
- rename something so that unconverted filesystems will reliably fail to
compile?
- leave existing filesystems alone, but add a new
inode_operations.setattr_jeff, which the networked filesytems can
On Wed, 8 Aug 2007 04:18:38 +0200 Nick Piggin [EMAIL PROTECTED] wrote:
On Tue, Aug 07, 2007 at 06:09:03PM -0700, Andrew Morton wrote:
On Tue, 7 Aug 2007 07:51:29 +0200
Nick Piggin [EMAIL PROTECTED] wrote:
nobh mode error handling is not just pretty slack, it's wrong.
One cannot
17 matches
Mail list logo
