* Re: udf: Prevent write-unsupported filesystem to be remounted read-write [not found] <124cc6ea-ca79-20f2-651e-c2f909729ac0@gmx.de> @ 2019-01-14 0:33 ` Kevin Weidemann 2019-01-14 10:30 ` Jan Kara 0 siblings, 1 reply; 15+ messages in thread From: Kevin Weidemann @ 2019-01-14 0:33 UTC (permalink / raw) To: Jan Kara; +Cc: linux-kernel 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 ^ permalink raw reply [flat|nested] 15+ messages in thread
* Re: udf: Prevent write-unsupported filesystem to be remounted read-write 2019-01-14 0:33 ` udf: Prevent write-unsupported filesystem to be remounted read-write Kevin Weidemann @ 2019-01-14 10:30 ` Jan Kara 2019-01-14 12:00 ` Pali Rohár ` (2 more replies) 0 siblings, 3 replies; 15+ messages in thread From: Jan Kara @ 2019-01-14 10:30 UTC (permalink / raw) To: Kevin Weidemann; +Cc: Jan Kara, linux-kernel, linux-fsdevel, Pali Rohár 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 ^ permalink raw reply [flat|nested] 15+ messages in thread
* Re: udf: Prevent write-unsupported filesystem to be remounted read-write 2019-01-14 10:30 ` Jan Kara @ 2019-01-14 12:00 ` Pali Rohár 2019-01-14 12:30 ` Jan Kara 2019-01-14 15:12 ` Pali Rohár 2019-01-22 13:22 ` Jan Kara 2 siblings, 1 reply; 15+ messages in thread From: Pali Rohár @ 2019-01-14 12:00 UTC (permalink / raw) To: Jan Kara; +Cc: Michael Sabolish, Kevin Weidemann, linux-kernel, linux-fsdevel 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 ^ permalink raw reply [flat|nested] 15+ messages in thread
* Re: udf: Prevent write-unsupported filesystem to be remounted read-write 2019-01-14 12:00 ` Pali Rohár @ 2019-01-14 12:30 ` Jan Kara 2019-01-15 3:07 ` Michael Sabolish 0 siblings, 1 reply; 15+ messages in thread From: Jan Kara @ 2019-01-14 12:30 UTC (permalink / raw) To: Pali Rohár Cc: Jan Kara, Michael Sabolish, Kevin Weidemann, linux-kernel, linux-fsdevel 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 ^ permalink raw reply [flat|nested] 15+ messages in thread
* Re: udf: Prevent write-unsupported filesystem to be remounted read-write 2019-01-14 12:30 ` Jan Kara @ 2019-01-15 3:07 ` Michael Sabolish 2019-01-15 8:31 ` Pali Rohár 0 siblings, 1 reply; 15+ messages in thread From: Michael Sabolish @ 2019-01-15 3:07 UTC (permalink / raw) To: Jan Kara; +Cc: Pali Rohár, Kevin Weidemann, linux-kernel, linux-fsdevel 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 ^ permalink raw reply [flat|nested] 15+ messages in thread
* Re: udf: Prevent write-unsupported filesystem to be remounted read-write 2019-01-15 3:07 ` Michael Sabolish @ 2019-01-15 8:31 ` Pali Rohár 2019-01-15 8:41 ` Jan Kara 0 siblings, 1 reply; 15+ messages in thread From: Pali Rohár @ 2019-01-15 8:31 UTC (permalink / raw) To: Michael Sabolish; +Cc: Jan Kara, Kevin Weidemann, linux-kernel, linux-fsdevel 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 ^ permalink raw reply [flat|nested] 15+ messages in thread
* Re: udf: Prevent write-unsupported filesystem to be remounted read-write 2019-01-15 8:31 ` Pali Rohár @ 2019-01-15 8:41 ` Jan Kara 2019-01-15 8:48 ` Pali Rohár 0 siblings, 1 reply; 15+ messages in thread From: Jan Kara @ 2019-01-15 8:41 UTC (permalink / raw) To: Pali Rohár Cc: Michael Sabolish, Jan Kara, Kevin Weidemann, linux-kernel, linux-fsdevel 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 ^ permalink raw reply [flat|nested] 15+ messages in thread
* Re: udf: Prevent write-unsupported filesystem to be remounted read-write 2019-01-15 8:41 ` Jan Kara @ 2019-01-15 8:48 ` Pali Rohár 2019-01-15 9:45 ` Jan Kara 0 siblings, 1 reply; 15+ messages in thread From: Pali Rohár @ 2019-01-15 8:48 UTC (permalink / raw) To: Jan Kara; +Cc: Michael Sabolish, Kevin Weidemann, linux-kernel, linux-fsdevel 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 ^ permalink raw reply [flat|nested] 15+ messages in thread
* Re: udf: Prevent write-unsupported filesystem to be remounted read-write 2019-01-15 8:48 ` Pali Rohár @ 2019-01-15 9:45 ` Jan Kara 2019-01-15 10:50 ` Pali Rohár 0 siblings, 1 reply; 15+ messages in thread From: Jan Kara @ 2019-01-15 9:45 UTC (permalink / raw) To: Pali Rohár Cc: Jan Kara, Michael Sabolish, Kevin Weidemann, linux-kernel, linux-fsdevel 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 ^ permalink raw reply [flat|nested] 15+ messages in thread
* Re: udf: Prevent write-unsupported filesystem to be remounted read-write 2019-01-15 9:45 ` Jan Kara @ 2019-01-15 10:50 ` Pali Rohár 2019-01-15 11:15 ` Jan Kara 0 siblings, 1 reply; 15+ messages in thread From: Pali Rohár @ 2019-01-15 10:50 UTC (permalink / raw) To: Jan Kara; +Cc: Michael Sabolish, Kevin Weidemann, linux-kernel, linux-fsdevel 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 ^ permalink raw reply [flat|nested] 15+ messages in thread
* Re: udf: Prevent write-unsupported filesystem to be remounted read-write 2019-01-15 10:50 ` Pali Rohár @ 2019-01-15 11:15 ` Jan Kara 0 siblings, 0 replies; 15+ messages in thread From: Jan Kara @ 2019-01-15 11:15 UTC (permalink / raw) To: Pali Rohár Cc: Jan Kara, Michael Sabolish, Kevin Weidemann, linux-kernel, linux-fsdevel 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 ^ permalink raw reply [flat|nested] 15+ messages in thread
* Re: udf: Prevent write-unsupported filesystem to be remounted read-write 2019-01-14 10:30 ` Jan Kara 2019-01-14 12:00 ` Pali Rohár @ 2019-01-14 15:12 ` Pali Rohár 2019-01-14 16:26 ` Kevin Weidemann 2019-01-22 13:22 ` Jan Kara 2 siblings, 1 reply; 15+ messages in thread From: Pali Rohár @ 2019-01-14 15:12 UTC (permalink / raw) To: Kevin Weidemann; +Cc: Jan Kara, linux-kernel, linux-fsdevel 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 ^ permalink raw reply [flat|nested] 15+ messages in thread
* Re: udf: Prevent write-unsupported filesystem to be remounted read-write 2019-01-14 15:12 ` Pali Rohár @ 2019-01-14 16:26 ` Kevin Weidemann 0 siblings, 0 replies; 15+ messages in thread From: Kevin Weidemann @ 2019-01-14 16:26 UTC (permalink / raw) To: Pali Rohár; +Cc: Jan Kara, linux-kernel, linux-fsdevel 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. ^ permalink raw reply [flat|nested] 15+ messages in thread
* Re: udf: Prevent write-unsupported filesystem to be remounted read-write 2019-01-14 10:30 ` Jan Kara 2019-01-14 12:00 ` Pali Rohár 2019-01-14 15:12 ` Pali Rohár @ 2019-01-22 13:22 ` Jan Kara 2019-01-23 20:29 ` Kevin Weidemann 2 siblings, 1 reply; 15+ messages in thread From: Jan Kara @ 2019-01-22 13:22 UTC (permalink / raw) To: Kevin Weidemann; +Cc: Jan Kara, linux-kernel, linux-fsdevel, Pali Rohár 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 ^ permalink raw reply [flat|nested] 15+ messages in thread
* Re: udf: Prevent write-unsupported filesystem to be remounted read-write 2019-01-22 13:22 ` Jan Kara @ 2019-01-23 20:29 ` Kevin Weidemann 0 siblings, 0 replies; 15+ messages in thread From: Kevin Weidemann @ 2019-01-23 20:29 UTC (permalink / raw) To: Jan Kara; +Cc: linux-kernel, linux-fsdevel, Pali Rohár 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| || ^ permalink raw reply [flat|nested] 15+ messages in thread
end of thread, other threads:[~2019-01-23 20:29 UTC | newest] Thread overview: 15+ messages (download: mbox.gz / follow: Atom feed) -- links below jump to the message on this page -- [not found] <124cc6ea-ca79-20f2-651e-c2f909729ac0@gmx.de> 2019-01-14 0:33 ` udf: Prevent write-unsupported filesystem to be remounted read-write Kevin Weidemann 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
This is a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox; as well as URLs for NNTP newsgroup(s).