Message-ID: <8cf39b7c-505b-91e6-849d-e66ba980042f@postn.eu>
Date:   Mon, 14 Jan 2019 01:33:30 +0100
From:   Kevin Weidemann <kwe-lnx@...tn.eu>
To:     Jan Kara <jack@...e.cz>
Cc:     linux-kernel@...r.kernel.org
Subject: Re: udf: Prevent write-unsupported filesystem to be remounted
 read-write

Hello,

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)
case B) when having a "readwrite udf" on a readonly device, the filesystem mounts as readwrite (!), but the writes end up being invisibly discarded

To me, B) sounds just like the kind of issue that the commit, that I mentioned above, promised 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

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?


[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)

--
Kind regards,
Kevin Weidemann

Powered by blists - more mailing lists