ENT-14297: Improve error message when cf-agent cannot write to an immutable file

[nickanderson]

Problem

When cf-agent cannot open a file for writing via the content attribute, the error gives no reason at all:

error: Cannot open file '/tmp/immutable.txt' for writing

The immutable bit (chattr +i) is frequently set deliberately to keep CFEngine from managing a file, and this generic message forces operators to investigate the underlying cause.

Change

The actual system error is now always reported, and when the file carries the immutable bit (and it is not being overridden) that is called out explicitly:

error: Cannot open file '/tmp/immutable.txt' for writing: Operation not permitted (the immutable bit is set)

Other failures now include the system error string, which the previous message omitted entirely:

error: Cannot open file '/etc/foo' for writing: Read-only file system

Jira: ENT-14297

[larsewi]

This only improves the message for when you are using the content attribute. Adding these checks everywhere would be quite tedious. Maybe it would be better to have OverrideImmutableBegin() take care of this logic?

[nickanderson]

This only improves the message for when you are using the content attribute. Adding these checks everywhere would be quite tedious. Maybe it would be better to have OverrideImmutableBegin() take care of this logic?

WTH, not all my commits are here and I thought they were, sorry. will get them up later

[nickanderson]

Good call — the previous version only covered the content attribute.

I looked at generalizing via OverrideImmutableBegin(), but that helper is only used by the content path. The shared landing point for edit_line, edit_xml, copy_from and both template engines is OverrideImmutableRename() — they all write a temporary file via SaveAsFile() and rename it over the target — so I moved the detection there. That covers all of them in one place without repeating the check at each call site.

The content path writes in place rather than renaming, so it keeps its own detection at the fopen() failure. Two points total:

• WriteContentFromString() — the in-place open (content)
• OverrideImmutableRename() — the temp→target rename (edit_line, edit_xml, copy_from, templating)

Both confirm the bit via FSAttrsGetImmutableFlag() rather than guessing from errno, and both are skipped when overriding (that path clears the bit and renames a temp copy into place).

Added acceptance tests for edit_line and copy_from (15/16) alongside content (14). Verified end-to-end against a real immutable file (KVM VM, ext4 root):

content:   Cannot open file '/c.txt' for writing: Operation not permitted (the immutable bit is set)
edit_line: Failed to replace original file '/e.txt' with copy '...': Operation not permitted (the immutable bit is set)
copy_from: Failed to replace original file '/d.txt' with copy '...': Operation not permitted (the immutable bit is set)

[larsewi]

I wonder if you could have used new_is_immutable from above in this condition instead?

[nickanderson]

Good instinct to reuse it, but new_is_immutable isn't valid in this branch: TemporarilyClearImmutableBit() returns early on !override without writing *was_immutable (and new_is_immutable is declared uninitialized), while this check runs specifically in the !override case — so reusing it here would read an uninitialized value. Keeping the explicit FSAttrsGetImmutableFlag() also keeps the extra stat on the rare rename-failure path rather than on every temp-file write. Happy to refactor TemporarilyClearImmutableBit() to always populate the flag if you'd prefer the reuse. (Analysis via Claude.)