backup.pl: Fixes bug13734 - tar treats colon in filename as remote location

  - When a user tries to restore on the console from a backup on IPFire that has a colon in
   the filename the tar treats this as meaning that everything after the colon is
   information about a remote location to do the extraction to. This results in a filename
   that cannot be found, and a remote location that is not correct and the tar operation
   fails.
- This has been confirmed by myself.
- If the user tries a restore from a file downloaded to another computer then for most, if
   not all browsers, the colon will have been replaced by an underscore or other character.
   Firefox, Chromium and Vivaldi do this.
- So any backup file that is selected to be restored using the WUI will no longer have a
   colon in the filename.
- This patch adds --force-local to the tar command, which means that tar will treat the
   colon as a character in the filename. This will ensure that if a user has any backup
   files stored on their IPFire system, with a colon in the filename then doing a restore
   from this file will not cause tar to fail.
- The NOW variable is also changed to replace the colon by a dash and to separate the date
   and time by an underscore. This filename will be accepted by browsers, without doing
   any replacements. Tested out with Firefox, Chromium & Vivaldi.
- The above ensures that both the new and old filename versions will work for doing a
   restore.

Fixes: bug13734
Tested-by: Adolf Belka <adolf.belka@ipfire.org>
Signed-off-by: Adolf Belka <adolf.belka@ipfire.org>
---
 config/backup/backup.pl | 7 ++++---
 1 file changed, 4 insertions(+), 3 deletions(-)
  

Adolf,

Suggested change for "NOW":  I believe users will find it is easier to read a date like 2024-08-07_10.57 (with a period separator for time) vs. 2024-08-07_10-58.

It is a small change but a helpful one for readability.



Jon


> On Aug 7, 2024, at 9:02 AM, Adolf Belka <adolf.belka@ipfire.org> wrote:
> 
> - When a user tries to restore on the console from a backup on IPFire that has a colon in
>  the filename the tar treats this as meaning that everything after the colon is
>  information about a remote location to do the extraction to. This results in a filename
>  that cannot be found, and a remote location that is not correct and the tar operation
>  fails.
> - This has been confirmed by myself.
> - If the user tries a restore from a file downloaded to another computer then for most, if
>  not all browsers, the colon will have been replaced by an underscore or other character.
>  Firefox, Chromium and Vivaldi do this.
> - So any backup file that is selected to be restored using the WUI will no longer have a
>  colon in the filename.
> - This patch adds --force-local to the tar command, which means that tar will treat the
>  colon as a character in the filename. This will ensure that if a user has any backup
>  files stored on their IPFire system, with a colon in the filename then doing a restore
>  from this file will not cause tar to fail.
> - The NOW variable is also changed to replace the colon by a dash and to separate the date
>  and time by an underscore. This filename will be accepted by browsers, without doing
>  any replacements. Tested out with Firefox, Chromium & Vivaldi.
> - The above ensures that both the new and old filename versions will work for doing a
>  restore.
> 
> Fixes: bug13734
> Tested-by: Adolf Belka <adolf.belka@ipfire.org>
> Signed-off-by: Adolf Belka <adolf.belka@ipfire.org>
> ---
> config/backup/backup.pl | 7 ++++---
> 1 file changed, 4 insertions(+), 3 deletions(-)
> 
> diff --git a/config/backup/backup.pl b/config/backup/backup.pl
> index d848084e9..7b2f95304 100644
> --- a/config/backup/backup.pl
> +++ b/config/backup/backup.pl
> @@ -2,7 +2,7 @@
> ###############################################################################
> #                                                                             #
> # IPFire.org - A linux based firewall                                         #
> -# Copyright (C) 2007-2022  IPFire Team  <info@ipfire.org>                     #
> +# Copyright (C) 2007-2024  IPFire Team  <info@ipfire.org>                     #
> #                                                                             #
> # This program is free software: you can redistribute it and/or modify        #
> # it under the terms of the GNU General Public License as published by        #
> @@ -21,7 +21,7 @@
> 
> shopt -s nullglob
> 
> -NOW="$(date "+%Y-%m-%d-%H:%M")"
> +NOW="$(date "+%Y-%m-%d_%H-%M")"
> 
> list_addons() {
> local file
> @@ -82,7 +82,8 @@ restore_backup() {
> # Extract backup
> if ! tar xvzpf "${filename}" -C / \
> --exclude-from="/var/ipfire/backup/exclude" \
> - --exclude-from="/var/ipfire/backup/exclude.user"; then
> + --exclude-from="/var/ipfire/backup/exclude.user" \
> + --force-local; then
> echo "Could not extract backup" >&2
> return 1
> fi
> -- 
> 2.45.2
> 




Jon Murphy
jon.murphy@ipfire.org
  

Hi Jon,

On 07/08/2024 18:05, jon wrote:
> Adolf,
>
> Suggested change for "NOW":  I believe users will find it is easier to read a date like 2024-08-07_10.57 (with a period separator for time) vs. 2024-08-07_10-58.

The change I put in was what was proposed by the user that reported the bug.

Maybe you could flag up your suggestion in the bug report to the originator to see what their feedback is.

Regards,

Adolf.

> It is a small change but a helpful one for readability.
>
>
>
> Jon
>
>
>> On Aug 7, 2024, at 9:02 AM, Adolf Belka <adolf.belka@ipfire.org> wrote:
>>
>> - When a user tries to restore on the console from a backup on IPFire that has a colon in
>>   the filename the tar treats this as meaning that everything after the colon is
>>   information about a remote location to do the extraction to. This results in a filename
>>   that cannot be found, and a remote location that is not correct and the tar operation
>>   fails.
>> - This has been confirmed by myself.
>> - If the user tries a restore from a file downloaded to another computer then for most, if
>>   not all browsers, the colon will have been replaced by an underscore or other character.
>>   Firefox, Chromium and Vivaldi do this.
>> - So any backup file that is selected to be restored using the WUI will no longer have a
>>   colon in the filename.
>> - This patch adds --force-local to the tar command, which means that tar will treat the
>>   colon as a character in the filename. This will ensure that if a user has any backup
>>   files stored on their IPFire system, with a colon in the filename then doing a restore
>>   from this file will not cause tar to fail.
>> - The NOW variable is also changed to replace the colon by a dash and to separate the date
>>   and time by an underscore. This filename will be accepted by browsers, without doing
>>   any replacements. Tested out with Firefox, Chromium & Vivaldi.
>> - The above ensures that both the new and old filename versions will work for doing a
>>   restore.
>>
>> Fixes: bug13734
>> Tested-by: Adolf Belka <adolf.belka@ipfire.org>
>> Signed-off-by: Adolf Belka <adolf.belka@ipfire.org>
>> ---
>> config/backup/backup.pl | 7 ++++---
>> 1 file changed, 4 insertions(+), 3 deletions(-)
>>
>> diff --git a/config/backup/backup.pl b/config/backup/backup.pl
>> index d848084e9..7b2f95304 100644
>> --- a/config/backup/backup.pl
>> +++ b/config/backup/backup.pl
>> @@ -2,7 +2,7 @@
>> ###############################################################################
>> #                                                                             #
>> # IPFire.org - A linux based firewall                                         #
>> -# Copyright (C) 2007-2022  IPFire Team  <info@ipfire.org>                     #
>> +# Copyright (C) 2007-2024  IPFire Team  <info@ipfire.org>                     #
>> #                                                                             #
>> # This program is free software: you can redistribute it and/or modify        #
>> # it under the terms of the GNU General Public License as published by        #
>> @@ -21,7 +21,7 @@
>>
>> shopt -s nullglob
>>
>> -NOW="$(date "+%Y-%m-%d-%H:%M")"
>> +NOW="$(date "+%Y-%m-%d_%H-%M")"
>>
>> list_addons() {
>> local file
>> @@ -82,7 +82,8 @@ restore_backup() {
>> # Extract backup
>> if ! tar xvzpf "${filename}" -C / \
>> --exclude-from="/var/ipfire/backup/exclude" \
>> - --exclude-from="/var/ipfire/backup/exclude.user"; then
>> + --exclude-from="/var/ipfire/backup/exclude.user" \
>> + --force-local; then
>> echo "Could not extract backup" >&2
>> return 1
>> fi
>> -- 
>> 2.45.2
>>
>
>
>
> Jon Murphy
> jon.murphy@ipfire.org
>
>
>
  

Reviewed-by: Bernhard Bitsch <bbitsch@ipfire.org>
Tested-by: Bernhard Bitsch <bbitsch@ipfire.org>


Am 07.08.2024 um 16:02 schrieb Adolf Belka:
> - When a user tries to restore on the console from a backup on IPFire that has a colon in
>     the filename the tar treats this as meaning that everything after the colon is
>     information about a remote location to do the extraction to. This results in a filename
>     that cannot be found, and a remote location that is not correct and the tar operation
>     fails.
> - This has been confirmed by myself.
> - If the user tries a restore from a file downloaded to another computer then for most, if
>     not all browsers, the colon will have been replaced by an underscore or other character.
>     Firefox, Chromium and Vivaldi do this.
> - So any backup file that is selected to be restored using the WUI will no longer have a
>     colon in the filename.
> - This patch adds --force-local to the tar command, which means that tar will treat the
>     colon as a character in the filename. This will ensure that if a user has any backup
>     files stored on their IPFire system, with a colon in the filename then doing a restore
>     from this file will not cause tar to fail.
> - The NOW variable is also changed to replace the colon by a dash and to separate the date
>     and time by an underscore. This filename will be accepted by browsers, without doing
>     any replacements. Tested out with Firefox, Chromium & Vivaldi.
> - The above ensures that both the new and old filename versions will work for doing a
>     restore.
> 
> Fixes: bug13734
> Tested-by: Adolf Belka <adolf.belka@ipfire.org>
> Signed-off-by: Adolf Belka <adolf.belka@ipfire.org>
> ---
>   config/backup/backup.pl | 7 ++++---
>   1 file changed, 4 insertions(+), 3 deletions(-)
> 
> diff --git a/config/backup/backup.pl b/config/backup/backup.pl
> index d848084e9..7b2f95304 100644
> --- a/config/backup/backup.pl
> +++ b/config/backup/backup.pl
> @@ -2,7 +2,7 @@
>   ###############################################################################
>   #                                                                             #
>   # IPFire.org - A linux based firewall                                         #
> -# Copyright (C) 2007-2022  IPFire Team  <info@ipfire.org>                     #
> +# Copyright (C) 2007-2024  IPFire Team  <info@ipfire.org>                     #
>   #                                                                             #
>   # This program is free software: you can redistribute it and/or modify        #
>   # it under the terms of the GNU General Public License as published by        #
> @@ -21,7 +21,7 @@
>   
>   shopt -s nullglob
>   
> -NOW="$(date "+%Y-%m-%d-%H:%M")"
> +NOW="$(date "+%Y-%m-%d_%H-%M")"
>   
>   list_addons() {
>   	local file
> @@ -82,7 +82,8 @@ restore_backup() {
>   	# Extract backup
>   	if ! tar xvzpf "${filename}" -C / \
>   			--exclude-from="/var/ipfire/backup/exclude" \
> -			--exclude-from="/var/ipfire/backup/exclude.user"; then
> +			--exclude-from="/var/ipfire/backup/exclude.user" \
> +			--force-local; then
>   		echo "Could not extract backup" >&2
>   		return 1
>   	fi