Release: 2.1.0.2 (Beta) 2024-11-29

@kenkendk , during my first on-disk backup since the upgrade to v2.1.0.2, I found a few other SELinux policies which required my attention when running on Fedora 41.

For BackendAsyncW:

module my-BackendAsyncW 1.0;

require {
	type unreserved_port_t;
	type unlabeled_t;
	type init_t;
	class tcp_socket name_connect;
	class dir remove_name;
	class file unlink;
}
allow init_t unlabeled_t:dir remove_name;
allow init_t unlabeled_t:file unlink;
allow init_t unreserved_port_t:tcp_socket name_connect;

Then duplicatiserve:

module my-duplicatiserve 1.0;

require {
	type tmp_t;
	type admin_home_t;
	type init_t;
	class process getsession;
	class fifo_file create;
	class file create;
}
allow init_t admin_home_t:file create;
allow init_t self:process getsession;
allow init_t tmp_t:fifo_file create;

Then NETTPWorker:

module my-NETTPWorker 1.0;

require {
	type unlabeled_t;
	type init_t;
	type http_port_t;
	type user_home_t;
	class tcp_socket name_connect;
	class file { create lock open read write };
	class dir add_name;
}
allow init_t http_port_t:tcp_socket name_connect;
allow init_t unlabeled_t:dir add_name;
allow init_t unlabeled_t:file create;
allow init_t unlabeled_t:file write;
allow init_t user_home_t:file { lock open read };

Because of an additional sync-script I run after the backup job, I needed these policies for WorkerThreadIR, too:

module my-WorkerThreadIR 1.0;

require {
	type user_home_t;
	type init_t;
	class lnk_file read;
	class file { execute execute_no_trans };
}
allow init_t user_home_t:file execute;
allow init_t user_home_t:file execute_no_trans;
allow init_t user_home_t:lnk_file read;

The script uses rsync, for which I had to add yet another custom SELinux policy:

module my-rsync 1.0;

require {
	type config_home_t;
	type unlabeled_t;
	type rsync_t;
	type user_home_dir_t;
	class file write;
	class dir search;
	class capability dac_override;
}
allow rsync_t config_home_t:file write;
allow rsync_t self:capability dac_override;
allow rsync_t unlabeled_t:dir search;
allow rsync_t user_home_dir_t:dir search;

Note: perhaps all these additional policies are not necessary on a vanilla installed, brand new system. Perhaps I have configured it to pieces, or something when awry on the update from Fedora 40 to 41. All I know at this moment, is that it works without any errors or warnings. But I do get the feeling I might have used a sledgehammer where a scalpel would have sufficed.

Could someone with insights into SELinux shed some light on this? Should my disks, folders and files be reconfigured, relabeled or what not?

Thanks, kind regards,
FWieP

No idea whether this is related to this update of course, but just tonight I noticed one of my backup jobs now terminates with the “database disk image is malformed” critical error. I tried “repair” and it finished instantly and didn’t help. I’m currently trying the “delete and rebuild” option, fingers crossed?

That indicates a failure in SQLite somehow, either internal error or disk error.

That sounds really strange. If the database is broken, the repair command should not be able to open it either.

That should work, as it will build the database again from scratch. Another attempt could have been the “vaccum” command, which will also recreate the database file, if it is readable.

I finally had time to go through all the necessary straddling on server and client side.

Note, not about this version, but about month newer version. Just updating this post because my previous statement was in this tread for context.

I updated with the “years end” version of Duplicati and tested the SFTP with it, and now it works. Interestingly still with aftp, there’s the problem that it asks for capabilities before login. But when I switched from AFTP to FTPS and set the encryption mode using CLI parameter, now it works as expected. All good, great! - Just confirmed my earlier expectations, that it requires probably extra effort to go through all the necessary options and find out fully working combination.

Just noting that the TLSv1.3 is not supported, but that’s currently acceptable.

I believe I found the cause for this and will make a patched beta release with this an a few other minor fixes.

It should work as it is using the OS TLS implementation. It is non-intuitive, but you need to set --ftp-ssl-protocols=None to get the OS default (which should be TLSv1.3).

Unfortunately, it seems Windows 10 does not support TLSv1.3 at all. Given that Win10 will be EOL this year, I am not sure it is worth pursuing.

There is a project to add custom TLSv1.3 to FTP, but it does not look smooth and only supports x64 for now:

The “at all” might be too strong. One can enable it and try. Don’t expect MS support.

Windows 10 and TLS 1.3 is one recent answer, and there might be others around

There are enough concerns IMO that it might not be worth the risk of taking chance.
This is especially true given some reports here where getting off 1.3 fixes problems.
I think the industry is on TLS 1.3 learning curve. Presumably Windows 11 is wiser


Hello, i tried to install the _beta_2024-11-29-linux-arm64-cli.deb an a Raspberry 4 using Raspbian bookworm. Sadly this error message appeared. Have anybody installed the version on an RPi4 or has another advice?
Thx Wolfgang

Paketlisten werden gelesen
AbhÀngigkeitsbaum wird aufgebaut
Statusinformationen werden eingelesen
Einige Pakete konnten nicht installiert werden. Das kann bedeuten, dass Sie eine unmögliche Situation angefordert haben, oder Sie die Unstable-Distribution verwenden, dass einige erforderliche Pakete noch nicht erstellt wurden oder Incoming noch nicht verlassen haben.
Die folgenden pakete haben unerfĂŒllte AbhĂ€ngigkeiten:
duplicati:arm64 : HĂ€ngt ab von libicu:arm64 ist aber nicht installierbar oder
libicu74:arm64 ist aber nicht installierbar oder
libicu72:arm64 ist aber nicht installierbar oder
libicu71:arm64 ist aber nicht installierbar oder
69,68,67,66,65,63,60,57,55,52
HĂ€ngt ab von: libss13:arm ist aber nicht installierbar oder
libssl1.1:arm64 ist aber nicht installierbar

Hi @nobody, welcome to the forum.

It is not an issue seen reported but I think @Taomyn has some experience with RPI?

Anyway, the problem is that the package is requesting libicu and libssl, and can use pretty much “any version”, but the Debian packages require having a specific version.

Do you know what versions of libicu and libss are available on your system?

Yes, I use it on a couple of RPi-4, but I don’t recall issues on arm64, only with arm7, both are also bookworm. The errors don’t mean much to me sorry.

Using what tool or method?

Was that retyped or manually built? It’s got a lot of oddities, e.g. libssl3 became libss13.
The list of numbers line is also missing 70, I wonder if arm should be arm64, and so on.

Maybe you can run apt list libssl3 to see what’s around and what’s installed there.
I have a hard time believing there’s no libssl3, but are you sure you’re on the 64 bit OS?