http://bugs.winehq.org/show_bug.cgi?id=59723 Bug ID: 59723 Summary: SetSecurityInfo does not persist DACL changes Product: Wine Version: 11.8 Hardware: x86-64 OS: Linux Status: UNCONFIRMED Severity: normal Priority: P2 Component: ntdll Assignee: wine-bugs@list.winehq.org Reporter: joel@airwebreathe.org.uk Distribution: --- Created attachment 80869 --> http://bugs.winehq.org/attachment.cgi?id=80869 reproducer.c (Found by AI testing) `SetSecurityInfo()` reports `ERROR_SUCCESS` when called to replace a file's DACL, but the DACL is not actually modified. Reading the DACL back (via either `GetSecurityInfo()` or `GetNamedSecurityInfoW()`) returns the original unchanged DACL. This also affects `SetNamedSecurityInfoW()`. ## Impact on MSYS2 The MSYS2/Cygwin runtime implements `chmod()` by translating POSIX mode bits into Windows ACL entries and calling `NtSetSecurityObject()` (which `SetSecurityInfo` wraps). Because the DACL is never actually updated: - `chmod()` appears to succeed but has no effect - `stat()` reads back the original permissions, not the ones set - `access()` checks against the wrong permissions - `umask()` has no observable effect on file creation modes This is the root cause for at least 6 test failures in the MSYS2 test suite: | Test | Symptom | |------|---------| | chmod01 | `chmod(0000)` → `stat()` still shows 0444; all 8 mode changes fail | | stat02 | `stat()` reports wrong mode after `chmod()` | | access01 | `access(file, X_OK)` wrong result because permissions unchanged | | access05 | `access()` returns 0 instead of -1 for file with read removed | | umask03 | Created files have wrong mode — umask bits not applied via ACL | | unlink08 | Directory permission changes don't take effect (partial overlap) | ## Reproducer ``` x86_64-w64-mingw32-gcc -o reproducer.exe reproducer.c -ladvapi32 wine reproducer.exe ``` ### Expected output (real Windows) ``` --- Step 2: Set DACL to single ACE (owner read-only) --- PASS: SetEntriesInAcl (1 ACE, read-only) PASS: SetSecurityInfo (protected DACL) --- Step 3: Read back DACL via handle --- PASS: GetSecurityInfo (re-read) After SetSecurityInfo: 1 ACEs [0] type=0 flags=0x00 mask=0x00120089 sid=S-1-5-21-...-1000 PASS: DACL has exactly 1 ACE PASS: ACE[0] is ACCESS_ALLOWED PASS: ACE[0] mask includes FILE_GENERIC_READ PASS: ACE[0] mask does NOT include GENERIC_WRITE bits ``` ### Actual output (Wine 11.4) ``` --- Step 2: Set DACL to single ACE (owner read-only) --- PASS: SetEntriesInAcl (1 ACE, read-only) PASS: SetSecurityInfo (protected DACL) --- Step 3: Read back DACL via handle --- PASS: GetSecurityInfo (re-read) After SetSecurityInfo: 3 ACEs [0] type=0 flags=0x00 mask=0x001f01ff sid=S-1-5-18 [1] type=0 flags=0x00 mask=0x001f01ff sid=S-1-5-21-0-0-0-1000 [2] type=0 flags=0x00 mask=0x001200a9 sid=S-1-1-0 FAIL: DACL has exactly 1 ACE (GetLastError=0) ``` The DACL still has 3 ACEs with the original permissions after the set call. ## Environment - Wine: 11.4 - Host: Linux x86_64 - Filesystem: ext4 (via wineprefix) ## Analysis The bug is in Wine's implementation of `NtSetSecurityObject()` (or the `SetSecurityInfo()` / `SetNamedSecurityInfoW()` wrappers). The function accepts the new security descriptor without error but does not write the new DACL to the underlying file's extended attributes or other backing store that Wine uses for ACL persistence. -- Do not reply to this email, post in Bugzilla using the above URL to reply. You are receiving this mail because: You are watching all bug changes.