mirror of https://lore.kernel.org/lkml/
 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   ` 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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox

all inboxes | Powered by JetHome®