Make options like "--umask" available for all Borg commands. #441

New Issue

Closed

opened 2021-08-16 14:47:10 +00:00 by ams_tschoening · 3 comments

ams_tschoening commented 2021-08-16 14:47:10 +00:00

Copy Link

What I'm trying to do and why

I have created a special backup user to execute BorgMatic and maintain it's config files, those files related to Borg itself etc. That user is having some entries for CRON associated which then execute the actual backups using sudo, so things run as root in the end. The point is that some tasks don't need to be done as root, e.g. listing and deleting archives, because those are stored on an external device.

The problem with this setup was that Borg applied a pretty restrictive umask of 077 by default, which prevented my special backup user from accessing those files created, updated etc. when running as root. The good news is that configs of BorgMatic (somewhat) prepare for those cases already using extra_borg_options and using those I can change the umask to a more permissive value of e.g. 0007. That seems to work for init, prune, create and check.

It doesn't seem to work for all other commands of interest supported by BorgMatic, like list. It as well doesn't seem to work when the special command borg is used to forward arbitrary unsupported commands. Would be great if one would be able to set those options for any commands.

Actual behavior

The following is when adding list to extra_borg_options. Thought it might work:

ams_d_bak_borg@amsoft:~$ sudo borgmatic --config ~/.config/borgmatic.d/mysql/files/de.am-soft.noc.yaml --verbosity 2 list
Ensuring legacy configuration is upgraded
/home/ams_d_bak_borg/.config/borgmatic.d/mysql/files/de.am-soft.noc.yaml: No valid configuration files found

summary:
/home/ams_d_bak_borg/.config/borgmatic.d/mysql/files/de.am-soft.noc.yaml: Error parsing configuration file
An error occurred while parsing a configuration file at /home/ams_d_bak_borg/.config/borgmatic.d/mysql/files/de.am-soft.noc.yaml:
At 'storage.extra_borg_options': Additional properties are not allowed ('list' was unexpected)
/home/ams_d_bak_borg/.config/borgmatic.d/mysql/files/de.am-soft.noc.yaml: No valid configuration files found

The following is without the former changes and shows that with list the default umask of Borg is used. This is the same for any other arbitrary Borg command.

ams_d_bak_borg@amsoft:~$ sudo borgmatic --config ~/.config/borgmatic.d/mysql/files/de.am-soft.noc.yaml --verbosity 2 list
Ensuring legacy configuration is upgraded
amsoft-sbox.bitstore.group:bak_borg/mysql/files/de.am-soft.noc: Listing archives
borg list --debug --show-rc amsoft-sbox.bitstore.group:bak_borg/mysql/files/de.am-soft.noc
using builtin fallback logging configuration
35 self tests completed in 0.04 seconds
SSH command line: ['ssh', '-F', '/home/ams_d_bak_borg/.ssh/config', 'amsoft-sbox.bitstore.group', 'borg', 'serve', '--umask=077', '--debug']
TAM-verified manifest
[...]

Expected behavior

Would be great to be able to forward options like umask really to all commands of Borg, because otherwise permission issues might happen. Remember that this option is not only applied for the repos, but for local cache, security etc. files maintained by Borg as well.

https://github.com/borgbackup/borg/issues/1859#issuecomment-261727374

--umask M set umask to M (local and remote, default: 0077)

Thanks for considering!

Environment

borgmatic version: 1.5.15
borgmatic installation method: PIP, system wide
Borg version: 1.1.16
Python version: 3.8.10
operating system and version: Ubuntu 20.04

#### What I'm trying to do and why I have created a special backup user to execute BorgMatic and maintain it's config files, those files related to Borg itself etc. That user is having some entries for CRON associated which then execute the actual backups using `sudo`, so things run as `root` in the end. The point is that some tasks don't need to be done as `root`, e.g. listing and deleting archives, because those are stored on an external device. The problem with this setup was that Borg applied a pretty restrictive `umask` of `077` by default, which prevented my special backup user from accessing those files created, updated etc. when running as `root`. The good news is that configs of BorgMatic (somewhat) prepare for those cases already using `extra_borg_options` and using those I can change the `umask` to a more permissive value of e.g. `0007`. That seems to work for `init`, `prune`, `create` and `check`. It doesn't seem to work for all other commands of interest supported by BorgMatic, like `list`. It as well doesn't seem to work when the special command `borg` is used to forward arbitrary unsupported commands. Would be great if one would be able to set those options for any commands. #### Actual behavior The following is when adding `list` to `extra_borg_options`. Thought it might work: ``` ams_d_bak_borg@amsoft:~$ sudo borgmatic --config ~/.config/borgmatic.d/mysql/files/de.am-soft.noc.yaml --verbosity 2 list Ensuring legacy configuration is upgraded /home/ams_d_bak_borg/.config/borgmatic.d/mysql/files/de.am-soft.noc.yaml: No valid configuration files found summary: /home/ams_d_bak_borg/.config/borgmatic.d/mysql/files/de.am-soft.noc.yaml: Error parsing configuration file An error occurred while parsing a configuration file at /home/ams_d_bak_borg/.config/borgmatic.d/mysql/files/de.am-soft.noc.yaml: At 'storage.extra_borg_options': Additional properties are not allowed ('list' was unexpected) /home/ams_d_bak_borg/.config/borgmatic.d/mysql/files/de.am-soft.noc.yaml: No valid configuration files found ``` The following is without the former changes and shows that with `list` the default `umask` of Borg is used. This is the same for any other arbitrary Borg command. ``` ams_d_bak_borg@amsoft:~$ sudo borgmatic --config ~/.config/borgmatic.d/mysql/files/de.am-soft.noc.yaml --verbosity 2 list Ensuring legacy configuration is upgraded amsoft-sbox.bitstore.group:bak_borg/mysql/files/de.am-soft.noc: Listing archives borg list --debug --show-rc amsoft-sbox.bitstore.group:bak_borg/mysql/files/de.am-soft.noc using builtin fallback logging configuration 35 self tests completed in 0.04 seconds SSH command line: ['ssh', '-F', '/home/ams_d_bak_borg/.ssh/config', 'amsoft-sbox.bitstore.group', 'borg', 'serve', '--umask=077', '--debug'] TAM-verified manifest [...] ``` #### Expected behavior Would be great to be able to forward options like `umask` really to all commands of Borg, because otherwise permission issues might happen. Remember that this option is not only applied for the repos, but for local cache, security etc. files maintained by Borg as well. https://github.com/borgbackup/borg/issues/1859#issuecomment-261727374 > --umask M set umask to M (local and remote, default: 0077) **Thanks for considering!** #### Environment **borgmatic version:** 1.5.15 **borgmatic installation method:** PIP, system wide **Borg version:** 1.1.16 **Python version:** 3.8.10 **operating system and version:** Ubuntu 20.04

ams_tschoening commented 2021-08-16 21:40:52 +00:00

Author

Copy Link

I had a look at my YAML file again and seem to have missed the already available storage.umask with the following documentation:

    # Umask to be used for borg create. Defaults to 0077.
    # umask: 0077

That made me wonder if that setting really is only applied to create or more and after looking at the code, it's applied to other commands like prune, mount etc. as well. Though, it's still not applied to all commands, I couldn't find check, list, borg etc.

The problem in my opinion is that while umask seems to make sense for changing commands only, BORG applies that value to locally maintained files for caches, security files etc. as well and some of those seem to be rewritten even if read-only oprations are applied to a repo only. So even after those permissions in locally maintained data might simply be wrong.

BORG documents that setting for all commands as well:

All Borg commands share these options:
[...]
--umask M set umask to M (local and remote, default: 0077)

https://borgbackup.readthedocs.io/en/stable/usage/general.html#common-options

I had a look at my YAML file again and seem to have missed the already available `storage.umask` with the following documentation: ``` # Umask to be used for borg create. Defaults to 0077. # umask: 0077 ``` That made me wonder if that setting really is only applied to `create` or more and after looking at the code, it's applied to other commands like `prune`, `mount` etc. as well. Though, it's still not applied to all commands, I couldn't find `check`, `list`, `borg` etc. The problem in my opinion is that while `umask` seems to make sense for changing commands only, BORG applies that value to locally maintained files for caches, security files etc. as well and some of those seem to be rewritten even if read-only oprations are applied to a repo only. So even after those permissions in locally maintained data might simply be wrong. BORG documents that setting for all commands as well: > All Borg commands share these options: > [...] > --umask M set umask to M (local and remote, default: 0077) https://borgbackup.readthedocs.io/en/stable/usage/general.html#common-options

witten added the

good first issue

label 2023-02-04 17:46:16 +00:00

witten referenced this issue 2023-03-23 21:13:07 +00:00

Allow restoring to other database server #326

witten referenced this issue from a commit 2024-11-18 17:10:29 +00:00

Apply the "umask" option to all relevant actions, not just some of them (#441).

witten commented 2024-11-18 17:10:33 +00:00

Owner

Copy Link

The umask option is now implemented for all relevant actions. This will be part of the next release!

The `umask` option is now implemented for all relevant actions. This will be part of the next release!

witten closed this issue 2024-11-18 17:10:33 +00:00

witten commented 2024-11-19 04:46:13 +00:00

Owner

Copy Link

Released in borgmatic 1.9.2!

Released in borgmatic 1.9.2!

Sign in to join this conversation.

No Branch/Tag Specified

Branches Tags

No results found.

1.9.8

1.9.7

1.9.6

1.9.5

1.9.4

1.9.3

1.9.2

1.9.1

1.9.0

1.8.14

1.8.13

1.8.12

1.8.11

1.8.10

1.8.9

1.8.8

1.8.7

1.8.6

1.8.5

1.8.4

1.8.3

1.8.2

1.8.1

1.8.0

1.7.15

1.7.14

1.7.13

1.7.12

1.7.11

1.7.10

1.7.9

1.7.8

1.7.7

1.7.6

1.7.5

1.7.4

1.7.3

1.7.2

1.7.1

1.7.0

1.6.6

1.6.5

1.6.4

1.6.3

1.6.2

1.6.1

1.6.0

1.5.24

1.5.23

1.5.22

1.5.21

1.5.20

1.5.19

1.5.18

1.5.17

1.5.16

1.5.15

1.5.14

1.5.13

1.5.12

1.5.11

1.5.10

1.5.9

1.5.8

1.5.7

1.5.7.dev0

1.5.6

1.5.5

1.5.4

1.5.3

1.5.2

1.5.1

1.5.0

1.4.22

1.4.21

1.4.20

1.4.19

1.4.18

1.4.17

1.4.16

1.4.15

1.4.14

1.4.13

1.4.12

1.4.11

1.4.10

1.4.9

1.4.8

1.4.7

1.4.6

1.4.5

1.4.4

1.4.3

1.4.2

1.4.1

1.4.0

1.3.26

1.3.25

1.3.24

1.3.23

1.3.22

1.3.21

1.3.20

1.3.19

1.3.18

1.3.17

1.3.16

1.3.15

1.3.14

1.3.13

1.3.12

1.3.11

1.3.10

1.3.9

1.3.8

1.3.7

1.3.6

1.3.5

1.3.4

1.3.3

1.3.2

1.3.1

1.3.0

1.2.18

1.2.17

1.2.16

1.2.15

1.2.14

1.2.13

1.2.12

1.2.11

1.2.10

1.2.9

1.2.8

1.2.7

1.2.6

1.2.5

1.2.4

1.2.3

1.2.2

1.2.1

1.2.0

1.1.15

1.1.14

1.1.13

1.1.12

1.1.11

1.1.10

1.1.9

1.1.7

1.1.6

1.1.5

1.1.4

1.1.3

1.1.2

1.1.1

1.1.0

1.0.3

1.0.2

1.0.1

1.0.0

0.1.8

0.1.7

0.1.6

0.1.5

0.1.4

0.1.3

0.1.2

0.1.1

0.1.0

0.0.7

0.0.6

0.0.5

0.0.4

0.0.3

0.0.2

Labels

Clear labels

blocked

bug

data loss

design finalized

good first issue

new feature area

question / support

security

waiting for response

No Label

good first issue

Milestone

No items

No Milestone

Assignees

Clear assignees

No Assignees

2 Participants

Notifications

Subscribe

Due Date

No due date set.

Dependencies

No dependencies set.

Reference: borgmatic-collective/borgmatic#441

No description provided.