borg 1.4 freebsd acl code does not compile on freebsd 13

[ThomasWaldmann]

The code does not compile on freebsd 13 due to using acl_extended_link_np to determine whether a file has ACLs beyond what the normal user/group/mode bits can express.

See src/borg/platform/freebsd.pyx.

So it seems the currently the minimum requirement for borg 1.4 on freebsd is freebsd >= 14.

[ThomasWaldmann]

I am not familiar with freebsd and ACLs on freebsd, so it would be good if a freebsd user / developer could help with this.

[ThomasWaldmann]

Workaround for freebsd 13 borg users: use borg 1.2.x for now.

[mandree]

The code comment also says to look at acl_is_trivial_np() - which has been around since 2009 so should be in FreeBSD 13. This is what FreeBSD 14.0's acl_extended_file_np and acl_extended_link_np are implemented like, and for the mainline (FreeBSD 15-CURRENT) you can select "main" in the upper right hand box. It basically looks if it's NFS4 or else just uses this acl_is_trivial_np().

https://cgit.freebsd.org/src/tree/lib/libc/posix1e/acl_extended_file_np.c?h=releng/14.0

[mandree]

I've fixed the FreeBSD port to support FreeBSD 13.3 by importing said file, so people using FreeBSD's latest packages should be good as of the upcoming 1.4.0_1, or can build from source today.

[ThomasWaldmann]

@mandree If you use freebsd and know about that stuff, can you fix the freebsd platform code in borg in a PR?

[mandree]

@ThomasWaldmann feasible, but please help me help you because I am rather unfamiliar with Cython still, and we need to decide and do something in your repo that I can solve trivially by different means in the FreeBSD ports framework, which defines a Makefile variable "OSVERSION" by default, and I depend on that to decide whether to inject the libc source code file and patch setup.py to list it on that.

We need to import the missing function only on older FreeBSD versions, and to find out if we are on an "older" version, we have a few options, please help me choose the right one in your context: Either we

• live with the current solution that only the official FreeBSD port I maintain supports FreeBSD 13.x (which is currently expected to go out of support end of April 2026), and let upstream move into the future without historic ballast,
• or look at FreeBSD's major version and do something if it's 13 explicitly (12 isn't supported any more),
• or, at configure time, test build and link a small C program that attempts to use the function, and if that fails, adds that .c file to the build (this is what I do not know yet how to formulate in Cython while I am proficient in Python, C++, C - I would have to get acquainted with Cython in far more detail than I currently care)
• or, in C - #include <sys/param.h> and look at one of the macros, __FreeBSD_version (of course we could use that in the source file, too, and build it unconditionally, which I would however like to avoid because then we need to revert that change once FreeBSD 13 goes out of support)

Further sources

• https://cgit.freebsd.org/ports/commit/archivers/py-borgbackup?id=bd04537abb28059580c84440c56a952d76067bd1 - how this is solved in FreeBSD
• https://cgit.freebsd.org/src/tree/sys/sys/param.h?h=releng%2F14.1#n48 - how FreeBSD versions are made - mistakes do happen, the added acl_extended_*_np did not lead to a bump at the time although it added something to the libc that a port might and did care about, but borg did not yet break in 2021.
• https://docs.freebsd.org/en/books/porters-handbook/versions/#versions-14 - unfortunately did not list posix1e additions nor bump the version directly
• https://www.freebsd.org/security/#sup - FreeBSD support periods

[ThomasWaldmann]

@mandree Hmm, maybe it would be easier to just use api calls that are also present on freebsd13? I wasn't even aware that I am using something that new when I implemented these changes...

[mandree]

Of course... if you want to change your source code, acl_is_trivial_np() is available on 13.3 as mentioned previously and as you can see in the acl_extended_file_np.c implementation file on 14.0 that I've linked to one message earlier.

But the FreeBSD port itself is already fixed and builds binary packages, too, so people can just run "pkg install py311-borgbackup" on supported FreeBSD 13 releases, too, and will get Borg Backup 1.4.0. Or "pkg install py311-borgbackup12" to get the prior version, 1.2.8. So I am not sure if you want to solve an issue again that I've fixed downstream in our FreeBSD packaging.

[ThomasWaldmann]

Note: This needs a PR from some freebsd user/developer to fix the borg acl code so it is freebsd 13 compatible. The fix should be to use only api calls that exist on fbsd < 13 AND to test these fixes (with the borg test suite and also practically).

[mikae1]

Workaround for freebsd 13 borg users: use borg 1.2.x for now.

Is borg 1.4.x “backward compatible”? That is, will borg 1.2.x work as source with a borg 1.4.0 installation that's used as a target for backups? The package manager on my Linux box will be stuck on the latest stable (1.4.x).

[ThomasWaldmann]

@mikae1 yes, that should work. Just make sure to use borg >= 1.2.5 (see the upgrade / CVE notes at the top of the changelog), using borg clients <= 1.2.4 together with clients >= 1.2.5 (including 1.4.x) can be problematic due to bugs in <= 1.2.4.

[mikae1]

@mikae1 yes, that should work. Just make sure to use borg >= 1.2.5 (see the upgrade / CVE notes at the top of the changelog), using borg clients <= 1.2.4 together with clients >= 1.2.5 (including 1.4.x) can be problematic due to bugs in <= 1.2.4.

Great, thanks for the swift reply! While I have you on the line… Will borg 1.4.x work as source with a 1.2.5 destination too?

[ThomasWaldmann]

Yes, that should also work.