https://bugs.documentfoundation.org/show_bug.cgi?id=174139
Bug ID: 174139
Summary: Windows CFA notification from Documents folder
initialization despite an explicitly configured
external work directory
Product: LibreOffice
Version: 26.8.1.1 release
Hardware: All
OS: Windows (All)
Status: UNCONFIRMED
Severity: normal
Priority: medium
Component: framework
Assignee: [email protected]
Reporter: [email protected]
Environment: Windows 11 Home x64, build 26200; LibreOffice 26.8.1.1 x64, build
bf6ef2662401c7d6dce671ab4deb26ee0af3a7c1. Microsoft Defender real-time
protection and Controlled Folder Access enabled; Smart App Control On.
Standard-user Office process.
Observed behavior: A headless conversion of a fictional FODT to ODT succeeds in
an explicitly selected folder on a mounted encrypted drive (exit 0, expected
document contents verified). Defender also records event 1123 identifying
soffice.bin as blocked from modifying %USERPROFILE%/Documents. The user
profile, Work, Backup and Temp paths are configured away from that folder.
Reproduction outline:
1. Use the above Windows and Office setup with CFA already enabled.
2. Use an explicit LibreOffice UserInstallation profile URL, Work directory and
--outdir on the mounted data drive. Supply a harmless FODT containing only test
text.
3. Run soffice.exe --headless --nologo --nodefault --norestore --convert-to odt
--outdir <test-output> <test-input.fodt> with that explicit profile.
4. Confirm output creation and review Microsoft-Windows-Windows
Defender/Operational for event 1123.
Expected: Resolving a default Windows folder should ideally not attempt
protected-folder modifications when the actual work/save directory is
elsewhere. Please confirm whether this is intended and whether there is a
supported configuration or fix.
Evidence: A Process Monitor export contains twelve events at
%USERPROFILE%/Documents: three directory create/open operations, three opens
requesting Write Attributes, each followed by CloseFile. All twelve Procmon
results are SUCCESS; a separate Defender CFA 1123 notification occurs for the
same run. Therefore this report does not claim Procmon directly captured a
denied operation. Native stack module sequence includes mergedlo.dll and
sal3.dll followed by Windows folder-service modules windows.storage.dll and
KernelBase.dll. Symbols beyond module offsets were not resolved.
Source-level lead: At the installed build revision, sal/osl/w32/security.cxx
uses GetSpecialFolder(FOLDERID_Documents) in osl_getHomeDir, and
GetSpecialFolder calls SHGetKnownFolderPath with KF_FLAG_CREATE.
framework/source/services/substitutepathvars.cxx initializes its home variable
through getHomeDir. This is a plausible explanation consistent with the stack,
not a proof that every instruction in that source path produced the
notification.
Sources:
https://raw.githubusercontent.com/LibreOffice/core/bf6ef2662401c7d6dce671ab4deb26ee0af3a7c1/sal/osl/w32/security.cxx
https://raw.githubusercontent.com/LibreOffice/core/bf6ef2662401c7d6dce671ab4deb26ee0af3a7c1/framework/source/services/substitutepathvars.cxx
Limitations: Initial captures used a profile with a custom Python toolbar
extension. A follow-up fresh-profile test, containing only explicit
Work/Backup/Temp path settings and no custom toolbar files, reproduced the same
CFA Documents block. Standard shared extensions remained installed (dict-en,
dict-es, dict-fr, nlpsolver, wiki-publisher); this was not a test with all
bundled extensions removed. The application and profile directories were
relocated/renamed; corresponding paths were repaired before the captured test.
A separate Python library warning was resolved with a process-local PYTHONHOME
pointing to the bundled runtime. The full original trace includes
machine-specific paths and is not attached; this report removes user/account
names, machine names, private project paths and identity details from the
diagnostic evidence.
No security exclusions, policy weakening, binary patching or Windows Documents
redirection were used. The vault save itself succeeds. Seeking a supported
correction for the unnecessary protected-folder access/notification.
Follow-up fresh-profile result: exit 0, fictional ODT contents verified, stderr
empty. Two Defender event 1123 records again identify soffice.bin blocked from
modifying %USERPROFILE%/Documents. The existing user profile remained
unchanged. This shows the custom toolbar is not required to reproduce the
behavior.
--
You are receiving this mail because:
You are the assignee for the bug.
