On Tue, Sep 27, 2016 at 10:35:08AM +0200, Jan Kara wrote: > > What I'd like is: Remove UNRM, SECRM and COMPR from USER_MODIFIABLE > bitmask. Return -EOPNOTSUPP when (flags & ~USER_MODIFIABLE) != 0. > This way we flag possible issues early and also using the so far unused > flags for any functionality in future is safe (otherwise you cannot be sure > whether some apps just randomly don't leave unused bits set). Whether some > apps won't get broken by this is a question but I'd hope not since as I > said other filesystems already behave this way and get away with that... > Are people willing to try this out? I'm uncomfortable returning an error but also making changes to the flags. If we return an error, we shouldn't be modifying the flags. I'm happy adding a new ioctl which returns an error without making any changes --- but that's something all file systems would have to support. I'm also happy having an ioctl which returns the current USER_MODIFIABLE bitmap (which is per-file system, by the way). > > > What I think would make sense is to simply remove UNRM, SECRM, and > > UNRM from the USER_MODIFIABLE bitmask. I also suspect it might be > > useful to define a new ioctl which returns the USER_VISIBLE and > > USER_MODIFIABLE bitmasks, so that tools can know how to expect (and > > give warning or error messages as desired). > > Well the GET/SETFLAGS ioctl is used by several filesystems these days so > we'd better check with other filesystems whether they are able to support > this functionality. As mentioned about, the USER_MODIFIABLE bitmask is a per-file system thing, so we can change it for ext4 without needing to consult with the other file systems. (It's EXT4_USER_MODIFIABLE_FL, IIRC). But I don't think we can return an error but also make changes to the flag fields, or make any changes to the actual behavior of the current ioctl without consulting the other file systems. That's why I think the better approach is to define a new ioctl that returns the user modifialbe and user visible bitmasks, and teach userspace to give warning messages (or error out entirely) if the user tries to set a flag which the file system is going to ignore. If the ioctl isn't defined for the other file systems, we'll fall back to the current behavior --- or if you like we can follow up the SETFLAGS with a GETFLAGS and then report a warning if the flags aren't checked. This to me is much more of an user interface issue for chattr than anything else, so I thin kit's better to fix this in chattr. - Ted -- To unsubscribe from this list: send the line "unsubscribe linux-ext4" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
