After the removal of the legacy RPC protocol with #9732 (with a few exceptions), support for UNIX socket communication via the socket: URI scheme and the --socket CLI option (for selecting a non-default socket path) was also removed.
UNIX socket communication was introduced to facilitate a range of different scenarios. It is a rather low-level feature. Low-level features such as this are not necessarily intended to encode specific workflows, but to provide composable building blocks. This allows users to address more niche or complex deployment requirements without Borg itself having to explicitly support or standardize every such scenario. It basically provides a foundation that can be combined with other tooling and system components.
Examples include:
My personal use case is creating full-system backups. In that scenario, borg create needs to run as root, while I would prefer the repo itself to be stored in a well-defined location and owned by a dedicated user (e.g. backup). Without UNIX socket support, this generally requires either changing ownership with chown after Borg operations complete, or using Borg's remote access mechanisms as a local privilege-separation workaround by connecting to localhost via SSH as a different user. See the 2023 discussion in #6183 for additional details and my personal motivation.
Thomas assessed in #9593 (comment) that reintroducing UNIX socket communication is not trivial, because Borg currently relies on three communication channels in the SSH-based implementation: stdin, stdout, and stderr. A UNIX domain socket, however, only provides a bidirectional data channel. Currently, the REST protocol uses stdin/stdout for protocol communication and stderr for logging and diagnostic output.
This limitation already existed when socket: and --socket support was originally introduced in 2023. It was possible to work around it at the time (see #6183 (comment) and #7604 for the 2023 analysis). However, I am not aware of the current situation, i.e. how heavily Borg now relies on stderr (if at all), whether a simple workaround (e.g., temporarily disabling remote logging) would be sufficient, or whether a REST protocol extension (see #9593) would be required to support UNIX sockets again.
Prior work:
Related (incomplete list):
After the removal of the legacy RPC protocol with #9732 (with a few exceptions), support for UNIX socket communication via the
socket:URI scheme and the--socketCLI option (for selecting a non-default socket path) was also removed.UNIX socket communication was introduced to facilitate a range of different scenarios. It is a rather low-level feature. Low-level features such as this are not necessarily intended to encode specific workflows, but to provide composable building blocks. This allows users to address more niche or complex deployment requirements without Borg itself having to explicitly support or standardize every such scenario. It basically provides a foundation that can be combined with other tooling and system components.
Examples include:
Local multi-user setups
borg serveis started on demand when a client connectsMore complex remote deployment scenarios
My personal use case is creating full-system backups. In that scenario,
borg createneeds to run as root, while I would prefer the repo itself to be stored in a well-defined location and owned by a dedicated user (e.g.backup). Without UNIX socket support, this generally requires either changing ownership withchownafter Borg operations complete, or using Borg's remote access mechanisms as a local privilege-separation workaround by connecting tolocalhostvia SSH as a different user. See the 2023 discussion in #6183 for additional details and my personal motivation.Thomas assessed in #9593 (comment) that reintroducing UNIX socket communication is not trivial, because Borg currently relies on three communication channels in the SSH-based implementation: stdin, stdout, and stderr. A UNIX domain socket, however, only provides a bidirectional data channel. Currently, the REST protocol uses stdin/stdout for protocol communication and stderr for logging and diagnostic output.
This limitation already existed when
socket:and--socketsupport was originally introduced in 2023. It was possible to work around it at the time (see #6183 (comment) and #7604 for the 2023 analysis). However, I am not aware of the current situation, i.e. how heavily Borg now relies on stderr (if at all), whether a simple workaround (e.g., temporarily disabling remote logging) would be sufficient, or whether a REST protocol extension (see #9593) would be required to support UNIX sockets again.Prior work:
--socketCLI option)Related (incomplete list):
--rsh#4749localhost: Backing up files owned by root #3587 (comment) / repo ownership/permissions #4082 (comment)