Re: udf: Prevent write-unsupported filesystem to be remounted read-write

[Jan Kara]

Hello,

On Mon 14-01-19 01:33:30, Kevin Weidemann wrote:
> this is RE the patch 8515b9edf7a0c9dcf1ad218ccc783700db217336 (Upstream
> commit a9ad01bc759df79b0012f43ee52164391e31cd96) in 4.18.20.
> 
> I have an issue with UDF. I used to be able to create a UDF fs in a way
> that is very similar to this:
> 
> `# mkudffs --label=.... -m dvd -b 512 /dev/mapper/cryptdev1`
> 
> I used to proceed mounting it, noticing it got mounted as readonly
> (because the accesstype of the udf fs is readonly (as decided per -m
> dvd)), so I remounted it as rw and then was able to fill it with data.[1]
> 
> Now, this doesn't work anymore since the last time I did that. I figured
> out it must have to do with the commit mentioned above.  All I get now,
> during a remount-as-rw attempt, is:
> `cannot remount /dev/mapper/cryptdev1 read-write, is write-protected`.
> 
> I am not sure if this counts as a regression, because I see the point in
> not only auto-mounting such filesystems as readonly, but also preventing
> remounting as rw, however it breaks my use case.
> 
> However, I noticed the following, too:
> case A) when having a "readonly udf" on a readwrite device, the
> filesystem mounts as readonly (old behavior) and also prevents remounting
> as rw (new behavior)

This works as intended.

> case B) when having a "readwrite udf" on a readonly device, the
> filesystem mounts as readwrite (!), but the writes end up being invisibly
> discarded

That's a bug. I'll fix it. Thanks for reporting this!

> To me, B) sounds just like the kind of issue that the commit, that I
> mentioned above, promised to fix.

Actually A) is what the commit a9ad01bc75 "udf: Prevent write-unsupported
filesystem to be remounted read-write" intended to fix.

> In fact, I believe case B to be more severe, because it automatically
> mounts as rw on a ro device, while the old (pre-patch) behavior of case A
> correctly mounted as ro and required manual remounting intervention to
> mount as rw on (potentially) rw - and even then, it's still less of an
> issue, when the underlying device is writeable.
> 
> I feel like the correct solution would be to:
> - disallow mounting as rw if the UDF is ro
> - disallow mounting as rw if the device is ro
> - disallow remounting as rw if the device is ro

Agreed on these.

> As for the case of remounting as rw if the UDF is ro but the device is
> rw, I am not sure what the best idea is to deal with this.  If this new
> behavior doesn't count as a regression, is there any way to end up with a
> UDF filesystem as specced by the command above (-m dvd -b 512, so with it
> being read-only), but still allow for mounting it as rw if the device
> supports it? Does udftools offer a way to manipulate the UDF partition
> descriptor flag in a pre-existing filesystem after it had already been
> created that I am missing?

So I would really prefer to keep the behavior of disallowing remounting
read-only partition read write. After all ECMA-167 standard is pretty clear
on this saying that for read-only partitions no sectors can be recorded. I
understand it is inconvenient if you try to create e.g. a DVD image. So you
want partition to be read-only in the end but initially you need it to be
writeable so that you can fill-in the contents.

Generally I think a clean solution for this is to provide a way in udftools
to switch partition read-only / read-write. Also this is how similar things
are achieved for other filesystems. Pali, is there a way to switch
accessType of a partition on existing media with udftools? If not, can you
look into implementing that please? It should be rather straightforward,
the biggest question really is which tool should do this...

								Honza

> [1] sanity check: people actually do this:
> - https://unix.stackexchange.com/a/17613
> - https://www.g-loaded.eu/2005/11/10/packet-writing-on-cdrw-and-dvdrw-media/
> - https://www.altlinux.org/WritingLargeFilesOnDVD
> - https://computador.docow.com/como-usair-dvd-rw-udf-tanto-no-windows-quanto-no-linux.html (case 4)
-- 
Jan Kara <jack@xxxxxxxx>
SUSE Labs, CR