All of lore.kernel.org
 help / color / mirror / Atom feed
From: Kevin Weidemann <kwe-lnx@postn.eu>
To: Jan Kara <jack@suse.cz>
Cc: linux-kernel@vger.kernel.org
Subject: Re: udf: Prevent write-unsupported filesystem to be remounted read-write
Date: Mon, 14 Jan 2019 01:33:30 +0100	[thread overview]
Message-ID: <8cf39b7c-505b-91e6-849d-e66ba980042f@postn.eu> (raw)
In-Reply-To: <124cc6ea-ca79-20f2-651e-c2f909729ac0@gmx.de>

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


       reply	other threads:[~2019-01-14  0:39 UTC|newest]

Thread overview: 15+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
     [not found] <124cc6ea-ca79-20f2-651e-c2f909729ac0@gmx.de>
2019-01-14  0:33 ` Kevin Weidemann [this message]
2019-01-14 10:30   ` udf: Prevent write-unsupported filesystem to be remounted read-write Jan Kara
2019-01-14 12:00     ` Pali Rohár
2019-01-14 12:30       ` Jan Kara
2019-01-15  3:07         ` Michael Sabolish
2019-01-15  8:31           ` Pali Rohár
2019-01-15  8:41             ` Jan Kara
2019-01-15  8:48               ` Pali Rohár
2019-01-15  9:45                 ` Jan Kara
2019-01-15 10:50                   ` Pali Rohár
2019-01-15 11:15                     ` Jan Kara
2019-01-14 15:12     ` Pali Rohár
2019-01-14 16:26       ` Kevin Weidemann
2019-01-22 13:22     ` Jan Kara
2019-01-23 20:29       ` Kevin Weidemann

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=8cf39b7c-505b-91e6-849d-e66ba980042f@postn.eu \
    --to=kwe-lnx@postn.eu \
    --cc=jack@suse.cz \
    --cc=linux-kernel@vger.kernel.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.