On Sunday 16 February 2025 21:43:02 Amir Goldstein wrote: > On Sun, Feb 16, 2025 at 9:24 PM Pali Rohár <pali@xxxxxxxxxx> wrote: > > > > On Sunday 16 February 2025 21:17:55 Amir Goldstein wrote: > > > On Sun, Feb 16, 2025 at 7:34 PM Eric Biggers <ebiggers@xxxxxxxxxx> wrote: > > > > > > > > On Sun, Feb 16, 2025 at 05:40:26PM +0100, Pali Rohár wrote: > > > > > This allows to get or set FS_COMPR_FL and FS_ENCRYPT_FL bits via FS_IOC_FSGETXATTR/FS_IOC_FSSETXATTR API. > > > > > > > > > > Signed-off-by: Pali Rohár <pali@xxxxxxxxxx> > > > > > > > > Does this really allow setting FS_ENCRYPT_FL via FS_IOC_FSSETXATTR, and how does > > > > this interact with the existing fscrypt support in ext4, f2fs, ubifs, and ceph > > > > which use that flag? > > > > > > As far as I can tell, after fileattr_fill_xflags() call in > > > ioctl_fssetxattr(), the call > > > to ext4_fileattr_set() should behave exactly the same if it came some > > > FS_IOC_FSSETXATTR or from FS_IOC_SETFLAGS. > > > IOW, EXT4_FL_USER_MODIFIABLE mask will still apply. > > > > > > However, unlike the legacy API, we now have an opportunity to deal with > > > EXT4_FL_USER_MODIFIABLE better than this: > > > /* > > > * chattr(1) grabs flags via GETFLAGS, modifies the result and > > > * passes that to SETFLAGS. So we cannot easily make SETFLAGS > > > * more restrictive than just silently masking off visible but > > > * not settable flags as we always did. > > > */ > > > > > > if we have the xflags_mask in the new API (not only the xflags) then > > > chattr(1) can set EXT4_FL_USER_MODIFIABLE in xflags_mask > > > ext4_fileattr_set() can verify that > > > (xflags_mask & ~EXT4_FL_USER_MODIFIABLE == 0). > > > > > > However, Pali, this is an important point that your RFC did not follow - > > > AFAICT, the current kernel code of ext4_fileattr_set() and xfs_fileattr_set() > > > (and other fs) does not return any error for unknown xflags, it just > > > ignores them. > > > > > > This is why a new ioctl pair FS_IOC_[GS]ETFSXATTR2 is needed IMO > > > before adding support to ANY new xflags, whether they are mapped to > > > existing flags like in this patch or are completely new xflags. > > > > > > Thanks, > > > Amir. > > > > But xflags_mask is available in this new API. It is available if the > > FS_XFLAG_HASEXTFIELDS flag is set. So I think that the ext4 improvement > > mentioned above can be included into this new API. > > > > Or I'm missing something? > > Yes, you are missing something very fundamental to backward compat API - > You cannot change the existing kernels. > > You should ask yourself one question: > What happens if I execute the old ioctl FS_IOC_FSSETXATTR > on an existing old kernel with the new extended flags? > > The answer, to the best of my code emulation abilities is that > old kernel will ignore the new xflags including FS_XFLAG_HASEXTFIELDS > and this is suboptimal, because it would be better for the new chattr tool > to get -EINVAL when trying to set new xflags and mask on an old kernel. > > It is true that the new chattr can call the old FS_IOC_FSGETXATTR > ioctl and see that it has no FS_XFLAG_HASEXTFIELDS, Yes, this was my intention how the backward and forward compatibility will work. I thought that reusing existing IOCTL is better than creating new IOCTL and duplicating functionality. > so I agree that a new ioctl is not absolutely necessary, > but I still believe that it is a better API design. If it is a bad idea then for sure I can prepare new IOCTL and move all new functionality only into the new IOCTL, no problem. > Would love to hear what other fs developers prefer. > > Thanks, > Amir.
