Hi,
attached is a second version of a patch that stores inode flags such as
S_IMMUTABLE, S_APPEND, etc. from i_flags to EXT3_I(inode)->i_flags when
inode is written to disk. The same thing is done on GETFLAGS ioctl.
Quota code changes these flags on quota files (to make it harder for
sysadmin to screw himself) and these changes were not correctly
propagated into the filesystem (especially, lsattr did not show them and
users were wondering...). Andrew, could you please put the patch into your
queue? Thanks.
Honza
--
Jan Kara <[email protected]>
SuSE CR Labs
On Tue, 17 Apr 2007 12:38:55 +0200 Jan Kara <[email protected]> wrote:
> attached is a second version of a patch that stores inode flags such as
> S_IMMUTABLE, S_APPEND, etc. from i_flags to EXT3_I(inode)->i_flags when
> inode is written to disk. The same thing is done on GETFLAGS ioctl.
> Quota code changes these flags on quota files (to make it harder for
> sysadmin to screw himself) and these changes were not correctly
> propagated into the filesystem (especially, lsattr did not show them and
> users were wondering...). Andrew, could you please put the patch into your
> queue? Thanks.
umm, OK.
What about ext2 and all the zillions of others?
On Fri 20-04-07 00:53:37, Andrew Morton wrote:
> On Tue, 17 Apr 2007 12:38:55 +0200 Jan Kara <[email protected]> wrote:
>
> > attached is a second version of a patch that stores inode flags such as
> > S_IMMUTABLE, S_APPEND, etc. from i_flags to EXT3_I(inode)->i_flags when
> > inode is written to disk. The same thing is done on GETFLAGS ioctl.
> > Quota code changes these flags on quota files (to make it harder for
> > sysadmin to screw himself) and these changes were not correctly
> > propagated into the filesystem (especially, lsattr did not show them and
> > users were wondering...). Andrew, could you please put the patch into your
> > queue? Thanks.
>
> umm, OK.
Thanks.
> What about ext2 and all the zillions of others?
Oh, yes... I'll send you patch for ext2, GFS2 and OCFS2. The only
filesystem, which is capable to store such flags and is not converted is
JFS - I was not able to find a suitable place for copying flags from VFS
inode to ondisk copy (giving CC to Shaggy)...
Honza
--
Jan Kara <[email protected]>
SuSE CR Labs
On Tue, 2007-04-17 at 12:38 +0200, Jan Kara wrote:
> Hi,
>
> attached is a second version of a patch that stores inode flags such as
> S_IMMUTABLE, S_APPEND, etc. from i_flags to EXT3_I(inode)->i_flags when
> inode is written to disk. The same thing is done on GETFLAGS ioctl.
> Quota code changes these flags on quota files (to make it harder for
> sysadmin to screw himself) and these changes were not correctly
> propagated into the filesystem (especially, lsattr did not show them and
> users were wondering...). Andrew, could you please put the patch into your
> queue? Thanks.
I think you need a call to ext3_get_inode_flags in one more place. In
ext3_ioctl(), EXT3_IOC_SETFLAGS modifies the flags based on what is in
ei->i_flags, so this code should make sure that ei->i_flags is in sync
with inode->i_flags.
Signed-off-by: Dave Kleikamp <[email protected]>
diff -Nurp linux-orig/fs/ext3/ioctl.c linux/fs/ext3/ioctl.c
--- linux-orig/fs/ext3/ioctl.c 2007-04-24 10:04:50.000000000 -0500
+++ linux/fs/ext3/ioctl.c 2007-04-24 10:05:59.000000000 -0500
@@ -51,6 +51,7 @@ int ext3_ioctl (struct inode * inode, st
flags &= ~EXT3_DIRSYNC_FL;
mutex_lock(&inode->i_mutex);
+ ext3_get_inode_flags(ei);
oldflags = ei->i_flags;
/* The JOURNAL_DATA flag is modifiable only by root */
--
David Kleikamp
IBM Linux Technology Center
On Tue 24-04-07 10:14:37, Dave Kleikamp wrote:
> On Tue, 2007-04-17 at 12:38 +0200, Jan Kara wrote:
> > Hi,
> >
> > attached is a second version of a patch that stores inode flags such as
> > S_IMMUTABLE, S_APPEND, etc. from i_flags to EXT3_I(inode)->i_flags when
> > inode is written to disk. The same thing is done on GETFLAGS ioctl.
> > Quota code changes these flags on quota files (to make it harder for
> > sysadmin to screw himself) and these changes were not correctly
> > propagated into the filesystem (especially, lsattr did not show them and
> > users were wondering...). Andrew, could you please put the patch into your
> > queue? Thanks.
>
> I think you need a call to ext3_get_inode_flags in one more place. In
> ext3_ioctl(), EXT3_IOC_SETFLAGS modifies the flags based on what is in
> ei->i_flags, so this code should make sure that ei->i_flags is in sync
> with inode->i_flags.
Hmm, I don't think so. The code does:
flags = flags & EXT3_FL_USER_MODIFIABLE;
flags |= oldflags & ~EXT3_FL_USER_MODIFIABLE;
ei->i_flags = flags;
So all EXT3_FL_USER_MODIFIABLE are overwritten by what user has supplied,
which happens to be a superset of flags influenced by
ext3_get_inode_flags(). On the other hand, from some point of view, after your
change the code is safer (in case we add some new unmodifiable flags) so I
don't object against adding the call. I just wanted to point out, that
currently there's no difference...
Honza
>
> Signed-off-by: Dave Kleikamp <[email protected]>
>
> diff -Nurp linux-orig/fs/ext3/ioctl.c linux/fs/ext3/ioctl.c
> --- linux-orig/fs/ext3/ioctl.c 2007-04-24 10:04:50.000000000 -0500
> +++ linux/fs/ext3/ioctl.c 2007-04-24 10:05:59.000000000 -0500
> @@ -51,6 +51,7 @@ int ext3_ioctl (struct inode * inode, st
> flags &= ~EXT3_DIRSYNC_FL;
>
> mutex_lock(&inode->i_mutex);
> + ext3_get_inode_flags(ei);
> oldflags = ei->i_flags;
>
> /* The JOURNAL_DATA flag is modifiable only by root */
>
> --
> David Kleikamp
> IBM Linux Technology Center
>
--
Jan Kara <[email protected]>
SuSE CR Labs
On Tue, 2007-04-24 at 17:35 +0200, Jan Kara wrote:
> On Tue 24-04-07 10:14:37, Dave Kleikamp wrote:
> > I think you need a call to ext3_get_inode_flags in one more place. In
> > ext3_ioctl(), EXT3_IOC_SETFLAGS modifies the flags based on what is in
> > ei->i_flags, so this code should make sure that ei->i_flags is in sync
> > with inode->i_flags.
> Hmm, I don't think so. The code does:
> flags = flags & EXT3_FL_USER_MODIFIABLE;
> flags |= oldflags & ~EXT3_FL_USER_MODIFIABLE;
> ei->i_flags = flags;
> So all EXT3_FL_USER_MODIFIABLE are overwritten by what user has supplied,
> which happens to be a superset of flags influenced by
> ext3_get_inode_flags(). On the other hand, from some point of view, after your
> change the code is safer (in case we add some new unmodifiable flags) so I
> don't object against adding the call. I just wanted to point out, that
> currently there's no difference...
Okay. I see that that's the case. I was thinking that individual flags
could be set through the ioctl, but it takes the whole set. I don't
really see the need to keep my patch from a safety perspective, but do
what you want.
Thanks,
Shaggy
--
David Kleikamp
IBM Linux Technology Center