Re: SECRM, UNRM, COMPR flags

On Sep 27, 2016, at 2:35 AM, Jan Kara [off-list ref] wrote:

On Mon 26-09-16 11:06:21, Ted Tso wrote:

quoted

On Mon, Sep 26, 2016 at 11:11:49AM +0200, Jan Kara wrote:

quoted

in ext4 we have these SECRM, UNRM, COMPR flags which users can set, they
can read them, but which actually don't do anything. This is actually
somewhat confusing - e.g. I've just got report about one tool which
apparently sets SECRM flag on a file in a hope that it is somehow safer.
Also this is a waste of flags.

I agree it doesn't seem very likely we'll be using UNRM any time soon.
I can imagine using SECRM and COMPR, but in particular for COMPR it
will probably be in a different way (the package manager would install
a file that would be compressed in userspace, and then using a
*different* ioctl from IOC_SETFLAGS, the COMPR flag would be set and
that would make the file immutable and the decompression would be done
in userspace).

quoted

I've checked other filesystems (xfs, btrfs) and they report EOPNOTSUPP if
these flags are not really supported. Should not we do the same in ext4? I
know there is a concern about breaking userspace but since other major
filesystems already behave this way I think there is a good chance tools
handle this reasonably... What do people thing?

What we've been doing for other flags that we don't set is that we
simply mask them off (see EXT4_FL_USER_MODIFIABLE) so attempt so set
them will be a no-op.

Yeah. This is better than what we currently have but still the problem is
that application can be tricked into thinking it got some functionality
when it actually did not (when ioctl succeeds, apps usually don't recheck
whether the bit actually got set - especially when other filesystems return
error in such case).

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 know in the past that the "NODUMP" flag wasn't used directly by ext*,
but it was used by the "dump" tool to skip backing up files.  It may be
that tar checks this as well, but not sure.

I could imagine that "UNRM" and "SECRM" could be checked by userspace
tools (LD_PRELOAD or some desktop garbage can?) in userspace to see if
the file should be put into .Trash or shredded at unlink time, but I
don't know if that was ever implemented.  It definitely was suggested
several times when people asked about implementing this in the kernel.

Cheers, Andreas

quoted

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. I think they should be and it could be useful for app
to know which info it is able to get/set so that it doesn't have to
research through trial and error. But this is IMO a separate issue to the
above ext4-specific problem.

								Honza
--
Jan Kara [off-list ref]
SUSE Labs, CR
--
To unsubscribe from this list: send the line "unsubscribe linux-ext4" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Cheers, Andreas