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

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

[Kevin Weidemann]

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

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@suse.com>
SUSE Labs, CR

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

[Pali Rohár]

Hello!

On Monday 14 January 2019 11:30:11 Jan Kara wrote:
> > 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...

You are not the first who asked for such functionality in udftools.
Michael (CCed) already experimented with such thing and "hacked"
udflabel to switch access type from overwritable to readonly.

I'm not against adding a new tool into udftools project which can
manipulate UDF access type. Question is design / API of such tool.

Currently udftools has udfinfo tool which prints lot of information
about UDF filesystem (including access type). But the only tool which
modifies UDF filesystem in udftools is udflabel. And udflabel is not
really the proper place for changing access type.

So some new tool for modifying UDF filesystem would be better. Which
other settings of UDF filesystem could be useful to be modifiable? I'm
thinking about "udftune" where new features for modification could be
implemented later too.

-- 
Pali Rohár
pali.rohar@gmail.com

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

[Jan Kara]

On Mon 14-01-19 13:00:23, Pali Rohár wrote:
> On Monday 14 January 2019 11:30:11 Jan Kara wrote:
> > > 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...
> 
> You are not the first who asked for such functionality in udftools.
> Michael (CCed) already experimented with such thing and "hacked"
> udflabel to switch access type from overwritable to readonly.
> 
> I'm not against adding a new tool into udftools project which can
> manipulate UDF access type. Question is design / API of such tool.
> 
> Currently udftools has udfinfo tool which prints lot of information
> about UDF filesystem (including access type). But the only tool which
> modifies UDF filesystem in udftools is udflabel. And udflabel is not
> really the proper place for changing access type.
> 
> So some new tool for modifying UDF filesystem would be better. Which
> other settings of UDF filesystem could be useful to be modifiable? I'm
> thinking about "udftune" where new features for modification could be
> implemented later too.

Yes, that sounds good to me and is in line with what tools for other
filesystems have.

								Honza
-- 
Jan Kara <jack@suse.com>
SUSE Labs, CR

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

[Michael Sabolish]

I can try and make a pull-request for udftune, and I can just copy the API for tune2fs.  It would work something like:

udftune -O read-only device            (to set read-only access type)

or:

udftune -O ^read-only device          (to clear read-only access type (aka set rw))


> On Jan 14, 2019, at 4:30 AM, Jan Kara <jack@suse.cz> wrote:
> 
> On Mon 14-01-19 13:00:23, Pali Rohár wrote:
>> On Monday 14 January 2019 11:30:11 Jan Kara wrote:
>>>> 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...
>> 
>> You are not the first who asked for such functionality in udftools.
>> Michael (CCed) already experimented with such thing and "hacked"
>> udflabel to switch access type from overwritable to readonly.
>> 
>> I'm not against adding a new tool into udftools project which can
>> manipulate UDF access type. Question is design / API of such tool.
>> 
>> Currently udftools has udfinfo tool which prints lot of information
>> about UDF filesystem (including access type). But the only tool which
>> modifies UDF filesystem in udftools is udflabel. And udflabel is not
>> really the proper place for changing access type.
>> 
>> So some new tool for modifying UDF filesystem would be better. Which
>> other settings of UDF filesystem could be useful to be modifiable? I'm
>> thinking about "udftune" where new features for modification could be
>> implemented later too.
> 
> Yes, that sounds good to me and is in line with what tools for other
> filesystems have.
> 
> 								Honza
> -- 
> Jan Kara <jack@suse.com>
> SUSE Labs, CR

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

[Pali Rohár]

On Monday 14 January 2019 19:07:35 Michael Sabolish wrote:
> I can try and make a pull-request for udftune, and I can just copy the API for tune2fs.  It would work something like:
> 
> udftune -O read-only device            (to set read-only access type)
> 
> or:
> 
> udftune -O ^read-only device          (to clear read-only access type (aka set rw))

This API is ambiguous. What does it mean for ^read-only? In UDF you have
following access types: overwritable, rewritable, writeonce, readonly,
pseudo-overwritable, unknown.

So you would need to know to which R/W access type to switch
(overwritable, rewritable, writeonce or pseudo-overwritable).

With information of media type, you could be able to guess correct
access type. But for UDF images stored in VFS there is no media
information. Also you can have uncommon setup, e.g. usage of CD-R
writeonce setup on CD-R/W disc. So "autodetection" of media type would
not work always correctly.

So I think that it would be better to have following API:

  udftune --access-type=<new_access_type>

or

  udftune --change-access-type=<new_access_type>

I understand that you would like to have similar API as tune2fs, but UDF
settings are too different from ext*.

-- 
Pali Rohár
pali.rohar@gmail.com

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

[Jan Kara]

On Tue 15-01-19 09:31:11, Pali Rohár wrote:
> On Monday 14 January 2019 19:07:35 Michael Sabolish wrote:
> > I can try and make a pull-request for udftune, and I can just copy the API for tune2fs.  It would work something like:
> > 
> > udftune -O read-only device            (to set read-only access type)
> > 
> > or:
> > 
> > udftune -O ^read-only device          (to clear read-only access type (aka set rw))
> 
> This API is ambiguous. What does it mean for ^read-only? In UDF you have
> following access types: overwritable, rewritable, writeonce, readonly,
> pseudo-overwritable, unknown.
> 
> So you would need to know to which R/W access type to switch
> (overwritable, rewritable, writeonce or pseudo-overwritable).
> 
> With information of media type, you could be able to guess correct
> access type. But for UDF images stored in VFS there is no media
> information. Also you can have uncommon setup, e.g. usage of CD-R
> writeonce setup on CD-R/W disc. So "autodetection" of media type would
> not work always correctly.
> 
> So I think that it would be better to have following API:
> 
>   udftune --access-type=<new_access_type>
> 
> or
> 
>   udftune --change-access-type=<new_access_type>
> 
> I understand that you would like to have similar API as tune2fs, but UDF
> settings are too different from ext*.

If you wanted to follow tune2fs interface, you can have e.g.:

udftune -E access-type=<foo>

Another question about the feature is - the access type is actually per
partition and there can be multiple partitions on UDF media. So I think we
need to specify the partition number in the command and <foo> has to
actually be something like <partition number>,<access_type>.

								Honza
-- 
Jan Kara <jack@suse.com>
SUSE Labs, CR

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

[Pali Rohár]

On Tuesday 15 January 2019 09:41:19 Jan Kara wrote:
> On Tue 15-01-19 09:31:11, Pali Rohár wrote:
> > On Monday 14 January 2019 19:07:35 Michael Sabolish wrote:
> > > I can try and make a pull-request for udftune, and I can just copy the API for tune2fs.  It would work something like:
> > > 
> > > udftune -O read-only device            (to set read-only access type)
> > > 
> > > or:
> > > 
> > > udftune -O ^read-only device          (to clear read-only access type (aka set rw))
> > 
> > This API is ambiguous. What does it mean for ^read-only? In UDF you have
> > following access types: overwritable, rewritable, writeonce, readonly,
> > pseudo-overwritable, unknown.
> > 
> > So you would need to know to which R/W access type to switch
> > (overwritable, rewritable, writeonce or pseudo-overwritable).
> > 
> > With information of media type, you could be able to guess correct
> > access type. But for UDF images stored in VFS there is no media
> > information. Also you can have uncommon setup, e.g. usage of CD-R
> > writeonce setup on CD-R/W disc. So "autodetection" of media type would
> > not work always correctly.
> > 
> > So I think that it would be better to have following API:
> > 
> >   udftune --access-type=<new_access_type>
> > 
> > or
> > 
> >   udftune --change-access-type=<new_access_type>
> > 
> > I understand that you would like to have similar API as tune2fs, but UDF
> > settings are too different from ext*.
> 
> If you wanted to follow tune2fs interface, you can have e.g.:

Question is if it is a good idea to follow this interface.

> udftune -E access-type=<foo>
> 
> Another question about the feature is - the access type is actually per
> partition and there can be multiple partitions on UDF media. So I think we
> need to specify the partition number in the command and <foo> has to
> actually be something like <partition number>,<access_type>.

Access type is stored in partition descriptor and in UDF (as opposite of
ECMA-167) you can have only one partition descriptor. IIRC there is some
exception when you have two partition descriptors, but then one have to be
readonly and second virtual.

-- 
Pali Rohár
pali.rohar@gmail.com

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

[Jan Kara]

On Tue 15-01-19 09:48:32, Pali Rohár wrote:
> On Tuesday 15 January 2019 09:41:19 Jan Kara wrote:
> > On Tue 15-01-19 09:31:11, Pali Rohár wrote:
> > > On Monday 14 January 2019 19:07:35 Michael Sabolish wrote:
> > > > I can try and make a pull-request for udftune, and I can just copy the API for tune2fs.  It would work something like:
> > > > 
> > > > udftune -O read-only device            (to set read-only access type)
> > > > 
> > > > or:
> > > > 
> > > > udftune -O ^read-only device          (to clear read-only access type (aka set rw))
> > > 
> > > This API is ambiguous. What does it mean for ^read-only? In UDF you have
> > > following access types: overwritable, rewritable, writeonce, readonly,
> > > pseudo-overwritable, unknown.
> > > 
> > > So you would need to know to which R/W access type to switch
> > > (overwritable, rewritable, writeonce or pseudo-overwritable).
> > > 
> > > With information of media type, you could be able to guess correct
> > > access type. But for UDF images stored in VFS there is no media
> > > information. Also you can have uncommon setup, e.g. usage of CD-R
> > > writeonce setup on CD-R/W disc. So "autodetection" of media type would
> > > not work always correctly.
> > > 
> > > So I think that it would be better to have following API:
> > > 
> > >   udftune --access-type=<new_access_type>
> > > 
> > > or
> > > 
> > >   udftune --change-access-type=<new_access_type>
> > > 
> > > I understand that you would like to have similar API as tune2fs, but UDF
> > > settings are too different from ext*.
> > 
> > If you wanted to follow tune2fs interface, you can have e.g.:
> 
> Question is if it is a good idea to follow this interface.

Agreed. I'll leave that decision up to you as a maintainer :)

> > udftune -E access-type=<foo>
> > 
> > Another question about the feature is - the access type is actually per
> > partition and there can be multiple partitions on UDF media. So I think we
> > need to specify the partition number in the command and <foo> has to
> > actually be something like <partition number>,<access_type>.
> 
> Access type is stored in partition descriptor and in UDF (as opposite of
> ECMA-167) you can have only one partition descriptor. IIRC there is some
> exception when you have two partition descriptors, but then one have to be
> readonly and second virtual.

Ah, right, I forgot that UDF standard limits how partitions can be set up.
However I don't see anything that would limit number of "type 1" maps? I've
only found in 2.2.4.7 that "Partition Maps shall be limited to Partition
Map type 1, except type 2 maps ...". In which I'm not sure whether this is
meant to imply there is only one 'type 1' partition map or whether there
can be more of them.

								Honza
-- 
Jan Kara <jack@suse.com>
SUSE Labs, CR

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

[Pali Rohár]

On Tuesday 15 January 2019 10:45:55 Jan Kara wrote:
> On Tue 15-01-19 09:48:32, Pali Rohár wrote:
> > On Tuesday 15 January 2019 09:41:19 Jan Kara wrote:
> > > On Tue 15-01-19 09:31:11, Pali Rohár wrote:
> > > > On Monday 14 January 2019 19:07:35 Michael Sabolish wrote:
> > > > > I can try and make a pull-request for udftune, and I can just copy the API for tune2fs.  It would work something like:
> > > > > 
> > > > > udftune -O read-only device            (to set read-only access type)
> > > > > 
> > > > > or:
> > > > > 
> > > > > udftune -O ^read-only device          (to clear read-only access type (aka set rw))
> > > > 
> > > > This API is ambiguous. What does it mean for ^read-only? In UDF you have
> > > > following access types: overwritable, rewritable, writeonce, readonly,
> > > > pseudo-overwritable, unknown.
> > > > 
> > > > So you would need to know to which R/W access type to switch
> > > > (overwritable, rewritable, writeonce or pseudo-overwritable).
> > > > 
> > > > With information of media type, you could be able to guess correct
> > > > access type. But for UDF images stored in VFS there is no media
> > > > information. Also you can have uncommon setup, e.g. usage of CD-R
> > > > writeonce setup on CD-R/W disc. So "autodetection" of media type would
> > > > not work always correctly.
> > > > 
> > > > So I think that it would be better to have following API:
> > > > 
> > > >   udftune --access-type=<new_access_type>
> > > > 
> > > > or
> > > > 
> > > >   udftune --change-access-type=<new_access_type>
> > > > 
> > > > I understand that you would like to have similar API as tune2fs, but UDF
> > > > settings are too different from ext*.
> > > 
> > > If you wanted to follow tune2fs interface, you can have e.g.:
> > 
> > Question is if it is a good idea to follow this interface.
> 
> Agreed. I'll leave that decision up to you as a maintainer :)
> 
> > > udftune -E access-type=<foo>
> > > 
> > > Another question about the feature is - the access type is actually per
> > > partition and there can be multiple partitions on UDF media. So I think we
> > > need to specify the partition number in the command and <foo> has to
> > > actually be something like <partition number>,<access_type>.
> > 
> > Access type is stored in partition descriptor and in UDF (as opposite of
> > ECMA-167) you can have only one partition descriptor. IIRC there is some
> > exception when you have two partition descriptors, but then one have to be
> > readonly and second virtual.
> 
> Ah, right, I forgot that UDF standard limits how partitions can be set up.
> However I don't see anything that would limit number of "type 1" maps? I've
> only found in 2.2.4.7 that "Partition Maps shall be limited to Partition
> Map type 1, except type 2 maps ...". In which I'm not sure whether this is
> meant to imply there is only one 'type 1' partition map or whether there
> can be more of them.

That is interesting question... I just found following:

In section "2. Basic Restrictions & Requirements" there is information
about "Partition Descriptor":

A Partition Descriptor Access Type of read-only, rewritable,
overwritable, write-once and pseudo-overwritable shall be supported.
There shall be exactly one prevailing Partition Descriptor recorded per
volume, with one exception. For Volume Sets that consist of single
volume, the volume may contain 2 non-overlapping Partitions with 2
prevailing Partition Descriptors only if one has an Access Type of
read-only and the other has an Access Type of rewritable, overwritable,
or write-once. The Logical Volume for this volume would consist of the
contents of both partitions.

But again it does not answer to your question.

-- 
Pali Rohár
pali.rohar@gmail.com

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

[Jan Kara]

On Tue 15-01-19 11:50:41, Pali Rohár wrote:
> On Tuesday 15 January 2019 10:45:55 Jan Kara wrote:
> > On Tue 15-01-19 09:48:32, Pali Rohár wrote:
> > > On Tuesday 15 January 2019 09:41:19 Jan Kara wrote:
> > > > On Tue 15-01-19 09:31:11, Pali Rohár wrote:
> > > > > On Monday 14 January 2019 19:07:35 Michael Sabolish wrote:
> > > > > > I can try and make a pull-request for udftune, and I can just copy the API for tune2fs.  It would work something like:
> > > > > > 
> > > > > > udftune -O read-only device            (to set read-only access type)
> > > > > > 
> > > > > > or:
> > > > > > 
> > > > > > udftune -O ^read-only device          (to clear read-only access type (aka set rw))
> > > > > 
> > > > > This API is ambiguous. What does it mean for ^read-only? In UDF you have
> > > > > following access types: overwritable, rewritable, writeonce, readonly,
> > > > > pseudo-overwritable, unknown.
> > > > > 
> > > > > So you would need to know to which R/W access type to switch
> > > > > (overwritable, rewritable, writeonce or pseudo-overwritable).
> > > > > 
> > > > > With information of media type, you could be able to guess correct
> > > > > access type. But for UDF images stored in VFS there is no media
> > > > > information. Also you can have uncommon setup, e.g. usage of CD-R
> > > > > writeonce setup on CD-R/W disc. So "autodetection" of media type would
> > > > > not work always correctly.
> > > > > 
> > > > > So I think that it would be better to have following API:
> > > > > 
> > > > >   udftune --access-type=<new_access_type>
> > > > > 
> > > > > or
> > > > > 
> > > > >   udftune --change-access-type=<new_access_type>
> > > > > 
> > > > > I understand that you would like to have similar API as tune2fs, but UDF
> > > > > settings are too different from ext*.
> > > > 
> > > > If you wanted to follow tune2fs interface, you can have e.g.:
> > > 
> > > Question is if it is a good idea to follow this interface.
> > 
> > Agreed. I'll leave that decision up to you as a maintainer :)
> > 
> > > > udftune -E access-type=<foo>
> > > > 
> > > > Another question about the feature is - the access type is actually per
> > > > partition and there can be multiple partitions on UDF media. So I think we
> > > > need to specify the partition number in the command and <foo> has to
> > > > actually be something like <partition number>,<access_type>.
> > > 
> > > Access type is stored in partition descriptor and in UDF (as opposite of
> > > ECMA-167) you can have only one partition descriptor. IIRC there is some
> > > exception when you have two partition descriptors, but then one have to be
> > > readonly and second virtual.
> > 
> > Ah, right, I forgot that UDF standard limits how partitions can be set up.
> > However I don't see anything that would limit number of "type 1" maps? I've
> > only found in 2.2.4.7 that "Partition Maps shall be limited to Partition
> > Map type 1, except type 2 maps ...". In which I'm not sure whether this is
> > meant to imply there is only one 'type 1' partition map or whether there
> > can be more of them.
> 
> That is interesting question... I just found following:
> 
> In section "2. Basic Restrictions & Requirements" there is information
> about "Partition Descriptor":
> 
> A Partition Descriptor Access Type of read-only, rewritable,
> overwritable, write-once and pseudo-overwritable shall be supported.
> There shall be exactly one prevailing Partition Descriptor recorded per
> volume, with one exception. For Volume Sets that consist of single
> volume, the volume may contain 2 non-overlapping Partitions with 2
> prevailing Partition Descriptors only if one has an Access Type of
> read-only and the other has an Access Type of rewritable, overwritable,
> or write-once. The Logical Volume for this volume would consist of the
> contents of both partitions.
> 
> But again it does not answer to your question.

Well, it does at least for the purposes of our discussion. Because even if
you would have more than one partition map, you would still have only one
partition descriptor and the access type is specified in the partition
descriptor, not in the partition map. So the above paragraph basically says
that we can set access type arbitrarily only if there is exactly one
partition descriptor. If there are two, we can switch partition only
between overwritable, write-once, pseudo-overwrite but I don't think that's
really useful. Thanks for enlightening me :).

								Honza
-- 
Jan Kara <jack@suse.com>
SUSE Labs, CR

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

[Pali Rohár]

On Monday 14 January 2019 11:30:11 Jan Kara wrote:
> On Mon 14-01-19 01:33:30, Kevin Weidemann wrote:
> > 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`

Hi Kevin! You should use -m dvd only in case your crtypdev1 device is
DVD. -m dvd prepares UDF filesystem layout and alignments for DVD media.

So you should not use -m dvd for hard disks.

Also DVDs have block size of 2048 bytes and UDF mandates that medium
block size matches UDF block size. Linux versions >= 4.11 do not have
problems with it, but other operating systems enforce that rule.

So you should not use -b 512 for DVD medias.

-- 
Pali Rohár
pali.rohar@gmail.com

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

[Kevin Weidemann]

On Monday 14 January 2019 at 16:12 Pali Rohár wrote:
> So you should not use -m dvd for hard disks.
>
> Also DVDs have block size of 2048 bytes and UDF mandates that medium
> block size matches UDF block size. Linux versions >= 4.11 do not have
> problems with it, but other operating systems enforce that rule.
>
> So you should not use -b 512 for DVD medias.

Hi Pali,

thanks for your pointers.
Interestingly enough, I chose that combination based on my test that
resulted in all (to me) relevant OSes (various Windows variants and my
set of Linux boxes) handling the resulting file system the way I
expected them to.
Choosing the bigger size of 2048 resulted in either issues when mounting
on Windows and/or having to pass a specific block size when mounting
under Linux, if I remember it correctly. It might have to do with the
block size of the block device under it. I think the point of using `-m
dvd` was to make the file system mount as read-only by default, though
it's been some months. I do remember checking what exactly `-m dvd` did
other than setting the access-type of the fs, but I must admit I don't
remember the result of that.

The main issue is, however, unaffected by this. I do agree that a
tune2fsque sort of tool as part of udftools would greatly improve the
situation.

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

[Jan Kara]

Hello,

On Mon 14-01-19 11:30:11, Jan Kara wrote:
> 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!

I have checked this and it works for me as designed:
(none):~# mount -t udf /dev/ubdb /mnt
mount: block device /dev/ubdb is write-protected, mounting read-only
UDF-fs: warning (device ubdb): udf_load_vrs: No anchor found
UDF-fs: Scanning with blocksize 512 failed
UDF-fs: warning (device ubdb): udf_load_vrs: No anchor found
UDF-fs: Scanning with blocksize 1024 failed
UDF-fs: INFO Mounting volume 'LinuxUDF', timestamp 2017/01/20 10:17 (1000)

So if the block device is read-only, you will get only read only mount.
Also remount read-write gets prevented:

(none):~# mount -o remount,rw /mnt/
mount: block device /dev/ubdb is write-protected, mounting read-only

Or with more recent util-linux (2.31.1):
(none):/ # mount -t udf /dev/ubdb /mnt
UDF-fs: warning (device ubdb): udf_load_vrs: No anchor found
UDF-fs: Scanning with blocksize 512 failed
UDF-fs: warning (device ubdb): udf_load_vrs: No anchor found
UDF-fs: Scanning with blocksize 1024 failed
UDF-fs: INFO Mounting volume 'LinuxUDF', timestamp 2017/01/20 10:17 (1000)
mount: /mnt: WARNING: device write-protected, mounted read-only.

and remount:
(none):/ # mount -o remount,rw /mnt
mount: /mnt: cannot remount /dev/ubdb read-write, is write-protected.

The kernel is 5.0-rc3. What kernel were you testing with?

								Honza
-- 
Jan Kara <jack@suse.com>
SUSE Labs, CR

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

[Kevin Weidemann]

Hello,

On Wednesday 22 January 2019 14:22 Jan Kara wrote
> The kernel is 5.0-rc3. What kernel were you testing with?

I don't remember exactly, but it was probably in the 4.20 line, as far
as I can tell.
The test case was a Veracrypt-compatible container file mounted with
cryptsetup using |the --readonly flag.|||
||

|--||
Kevin Weidemann|
||