Secure_cp creates .cfsaved file with 0 byte length in version 3.25.0

[birigli]

Hello,

the problem above is only the effect of a strange behaviour. The original file (which is the destination file) gets truncated to 0 byte, and later copied to .cfsaved file, hence it is 0 byte too. However it means the original/destination file is 0 byte length for a while, what can cause further problems when that file is read during that period (which is very short in human terms). I run cf-agent with strace, here is the relevant section (note: the ssh_config was used for demonstration purpose):

[pid 1145045] 10:54:10 newfstatat(4, "sshd_config", {st_mode=S_IFREG|0600, st_size=3449, ...}, AT_SYMLINK_NOFOLLOW) = 0
[pid 1145045] 10:54:10 openat(4, "sshd_config", O_WRONLY) = 5
[pid 1145045] 10:54:10 fstat(5, {st_mode=S_IFREG|0600, st_size=3449, ...}) = 0
[pid 1145045] 10:54:10 ftruncate(5, 0) = 0
[pid 1145045] 10:54:10 fcntl(5, F_GETFL) = 0x8001 (flags O_WRONLY|O_LARGEFILE)
[pid 1145045] 10:54:10 close(5)
.
.
[pid 1145045] 10:54:10 openat(4, "sshd_config.cfsaved", O_WRONLY|O_CREAT|O_EXCL, 0100600) = 6
[pid 1145045] 10:54:10 ftruncate(6, 0) = 0
[pid 1145045] 10:54:10 close(6) = 0

I omitted a lot of calls, but the very core regarding the problem, as you can see our file (ssh_config) is opened WRONLY, and then truncated to 0 byte (before it was 3449), after that some checks are done, old .cfsaved removed, a .cfnew file is created and loaded with data, and at last the "copy" of sshd_config to sshd_config.cfsaved (which is obviously ends right after the truncate call).
I attach the full trace.
trace_25_a.txt

Regards,
Balázs Varga

[larsewi]

Hi @birigli,

Thanks for reaching out!

What you are experiencing sounds very familiar. It may actually already have been fixed in this PR. Could you try running your policy with one of the master nightlies packages? Or maybe you could send a short policy snippet with a reproducer?

[birigli]

Hi,

thank you for the rapid answer, sure I try it and report back.

[birigli]

Hi again,

everything works fine now (v. 3.26.0a.824bd0c6c~614.ubuntu22). Will it be backported to 3.25? Or when will be 3.26 released? I'd prefer to install it from repo.

[larsewi]

Thanks for checking 🚀

We normally don't backport fixes to non-LTS branches. The next non-LTS release 3.26 is planned for May 15th and will include the fix.

However, the bug should not be present in the latest LTS release 3.24.1 if you don't mind downgrading. The LTS branches are usually more stable.

[larsewi]

@birigli I just wanted to let you know that 3.26 has been released. You can read more about it here

[birigli]

Many thanks!