> 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 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.
> >
> 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 in
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 retur
(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
> > > > ch
On Mon, 2007-08-06 at 21:37 +0200, Miklos Szeredi wrote:
> > > 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
> > 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, that would be fine. But I gues
On Mon, 2007-08-06 at 20:28 +0200, Miklos Szeredi wrote:
> 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
> > I agree with this change and fuse will make use of it as well.
> >
> > Maybe instead of unconditionally moving attr_kill_to_mode() inside
> > ->setattr() it could be made conditional based on an inode flag
> > similarly to S_NOCMTIME. Advantages:
> >
> > - no need to modify a lot of in-tree
On Mon, 06 Aug 2007 19:43:46 +0200
Miklos Szeredi <[EMAIL PROTECTED]> wrote:
> > Separate the handling of the local ia_valid bitmask from the one in
> > attr->ia_valid. This allows us to hand off the actual handling of the
> > ATTR_KILL_* flags to the .setattr i_op when one is defined.
> >
> > no
> Separate the handling of the local ia_valid bitmask from the one in
> attr->ia_valid. This allows us to hand off the actual handling of the
> ATTR_KILL_* flags to the .setattr i_op when one is defined.
>
> notify_change still needs to process those flags for the local ia_valid
> variable, since
11 matches
Mail list logo
