puppetlabs/puppet · error · Puppet::Util::Windows::Error

Failed to set security information

Error message

Failed to set security information

What it means

Raised when SetSecurityInfo returns a non-success code while writing owner, group, and DACL to a file handle opened with READ_CONTROL|WRITE_DAC|WRITE_OWNER. Common Win32 reasons folded into this one message are access denied (ERROR_ACCESS_DENIED, no WRITE_DAC on the object), an owner/group the caller may not assign, or an invalid ACL/SID in the payload. The appended Win32 text from Puppet::Util::Windows::Error gives the exact reason.

Source

Thrown at lib/puppet/util/windows/security.rb:684

                    raise "We should never get here"
                    # TODO: this should have been a warning in an earlier commit
                  end
                end

                # protected means the object does not inherit aces from its parent
                flags = OWNER_SECURITY_INFORMATION | GROUP_SECURITY_INFORMATION | DACL_SECURITY_INFORMATION
                flags |= sd.protect ? PROTECTED_DACL_SECURITY_INFORMATION : UNPROTECTED_DACL_SECURITY_INFORMATION

                rv = SetSecurityInfo(handle,
                                     :SE_FILE_OBJECT,
                                     flags,
                                     owner_sid_ptr,
                                     group_sid_ptr,
                                     acl_ptr,
                                     FFI::MemoryPointer::NULL)

                if rv != FFI::ERROR_SUCCESS
                  raise Puppet::Util::Windows::Error, _("Failed to set security information")
                end
              end
            end
          end
        end
      end
    end
  end

  ffi_convention :stdcall

  # https://msdn.microsoft.com/en-us/library/windows/desktop/aa363858(v=vs.85).aspx
  # HANDLE WINAPI CreateFile(
  #   _In_      LPCTSTR lpFileName,
  #   _In_      DWORD dwDesiredAccess,
  #   _In_      DWORD dwShareMode,
  #   _In_opt_  LPSECURITY_ATTRIBUTES lpSecurityAttributes,
  #   _In_      DWORD dwCreationDisposition,

View on GitHub (pinned to e227c27540)

Solutions

  1. Read e.code / appended message: 5 = access denied, 1307 = invalid owner
  2. Run elevated; only then can owner be set to arbitrary SIDs via SE_RESTORE_NAME/SE_TAKE_OWNERSHIP
  3. Grant the agent account WRITE_DAC on the subtree (or take ownership once) before managing ACLs there
  4. Verify every SID in the new descriptor with Puppet::Util::Windows::SID.valid_sid? before applying
Defensive patterns

Strategy: try-catch

Validate before calling

unless Puppet::Util::Windows::SID.valid_sid?(sd.owner) && Puppet::Util::Windows::SID.valid_sid?(sd.group)
  raise Puppet::Error, 'owner/group must be valid S-1-x-y SID strings'
end
# setting owner to another principal requires elevation (SeRestore/SeTakeOwnership)

Try / catch

begin
  Puppet::Util::Windows::Security.set_security_descriptor(path, sd)
rescue Puppet::Util::Windows::Error => e
  raise Puppet::Error, "No WRITE_DAC on #{path}; elevate or grant rights" if e.code == 5
  raise Puppet::Error, "Owner #{sd.owner} not assignable by this token; elevate" if e.code == 1307
  raise
end

Prevention

When it happens

Trigger: set_security_descriptor where the agent lacks WRITE_DAC/WRITE_OWNER on the target, where the new owner SID belongs to another principal without SE_RESTORE/SE_TAKE_OWNERSHIP held, where a SID in the DACL failed validation, or where the protect flag combination (PROTECTED vs UNPROTECTED DACL) conflicted with inheritance.

Common situations: Managing owner/group on files owned by Administrators/TrustedInstaller while running non-elevated; manifests setting owner to a different user than the agent runs as (Windows only allows assigning yourself, or anyone with restore privilege); system directories that resist DACL writes.

Related errors


AI-assisted analysis of puppetlabs/puppet@e227c27540 (2026-08-21). Data as JSON: /api/errors/08f38e0439252ee3. Report an issue: GitHub.