Message-Id: <0538A2EF-96CC-467E-8923-F7E2F9F8A800@dilger.ca>
Date:   Tue, 27 Sep 2016 05:45:09 -0600
From:   Andreas Dilger <adilger@...ger.ca>
To:     Jan Kara <jack@...e.cz>
Cc:     Theodore Ts'o <tytso@....edu>, linux-ext4@...r.kernel.org
Subject: Re: SECRM, UNRM, COMPR flags

On Sep 27, 2016, at 2:35 AM, Jan Kara <jack@...e.cz> wrote:
> 
> On Mon 26-09-16 11:06:21, Ted Tso wrote:
>> On Mon, Sep 26, 2016 at 11:11:49AM +0200, Jan Kara wrote:
>>> 
>>> 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).
>> 
>>> 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

>> 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 <jack@...e.com>
> SUSE Labs, CR
> --
> To unsubscribe from this list: send the line "unsubscribe linux-ext4" in
> the body of a message to majordomo@...r.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html


Cheers, Andreas






Download attachment "signature.asc" of type "application/pgp-signature" (834 bytes)

Powered by blists - more mailing lists