Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

xFileSystemAccessRule: "The security identifier is not allowed to be the owner of this object." #3

Closed
oleksii-iaroshchuk opened this issue Oct 24, 2016 · 6 comments · Fixed by #4
Labels
bug The issue is a bug. high priority The issue or PR should be resolved first. It is of less priority than the label 'Blocking Release'.

Comments

@oleksii-iaroshchuk
Copy link

I have the following simple rule to give "Modify" permission on the directory:

File WorkerRoleContent
{
    Ensure          = "Present"            
    DestinationPath = $workerRoleContentDir
    Type            = "Directory"    
}
xFileSystemAccessRule WorkerRoleContent
{
    DependsOn       = "[File]WorkerRoleContent"
    Path            = $workerRoleContentDir
    Identity        = $appUserName
    Rights          = "Modify"
    Ensure          = "Present"
}

When I apply this DSC configuration to clean system (no directory exists), everything works fine.
But when applying it on VM with already existing directory, I have the following error:

The security identifier is not allowed to be the owner of this object.

Googling a bit gave some results for Powershell Set-Acl cmdlet: http://www.mickputley.net/2015/11/set-acl-security-identifier-is-not.html
So, for now I implemented the following workaround using a Script resource:

Script WorkerRoleContent
{
    DependsOn = "[File]WorkerRoleContent"
    SetScript = {                
        $acl = (Get-Item $using:workerRoleContentDir).GetAccessControl('Access')
        $accessRule = New-Object System.Security.AccessControl.FileSystemAccessRule($using:appUserName, 
            "Modify", "ContainerInherit, ObjectInherit", "None", "Allow")
        $acl.SetAccessRule($accessRule)
        Set-ACL $using:workerRoleContentDir $acl
    }
    TestScript = { 
        return $false 
    }
    GetScript = {
        @{ Result = "WorkerRoleContent directory" }
    }
}

As stated in refrenced article, main idea is to use (Get-Item $FolderPath).GetAccessControl('Access') instead of Get-ACL $FolderPath.

It seems like such fix must be used inside of xFileSystemAccessRule resource.

@johlju johlju transferred this issue from dsccommunity/xSystemSecurity Mar 9, 2020
@johlju
Copy link
Member

johlju commented Mar 9, 2020

There was a fix for this that was not moved over here which means we could have an regression issue in this module now. See potential fix here https://github.com/dsccommunity/xSystemSecurity/pull/14/files.

@johlju johlju added the needs investigation The issue needs to be investigated by the maintainers or/and the community. label Mar 9, 2020
@bendwyer
Copy link
Contributor

bendwyer commented Apr 9, 2020

I am experiencing the same behavior when removing rights from an existing directory.

Failed to invoke DSC Set method: The security identifier is not allowed to be the owner of this object.

@johlju - to implement your proposed fix, can I simply replace the necessary files with the ones in your link?

@johlju
Copy link
Member

johlju commented Apr 9, 2020

@bendwyer I think replacing the files will remove other things. I think you need to copy and replace/add the green marked code into the correct place in the corresponding files in this repo.

I would appreciate it a lot if you could give it a try. Let me know if you get stuck in any way. 🙂

@johlju johlju added high priority The issue or PR should be resolved first. It is of less priority than the label 'Blocking Release'. bug The issue is a bug. help wanted The issue is up for grabs for anyone in the community. and removed needs investigation The issue needs to be investigated by the maintainers or/and the community. labels Apr 10, 2020
@bendwyer
Copy link
Contributor

Hi @johlju
I was able to make the changes to DSC_FileSystemAccessRule.psm1 and do some light testing. So far it's working. I did not update the DSC_FileSystemAccessRule.Tests.ps1 file as I don't really know what I would be doing there.

Would you like me to open a pull request with the updated file, or attach it here?

@johlju
Copy link
Member

johlju commented Apr 14, 2020

Awesome! Yes, please open a pull request and then I can help out with the unit tests.

@johlju johlju added in progress The issue is being actively worked on by someone. and removed help wanted The issue is up for grabs for anyone in the community. labels Apr 19, 2020
@johlju johlju closed this as completed in #4 Apr 19, 2020
johlju pushed a commit that referenced this issue Apr 19, 2020
#4)

- FileSystemAccessRule
  - Fixed an issue where the owner of ACL was written back resulting in an
    error "The security identifier is not allowed to be the owner of this
    object" (issue #3).
@johlju johlju removed the in progress The issue is being actively worked on by someone. label Apr 19, 2020
@johlju
Copy link
Member

johlju commented Apr 19, 2020

@bendwyer Thank you for the PR! I will release a new release as soon as the tests passes.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
bug The issue is a bug. high priority The issue or PR should be resolved first. It is of less priority than the label 'Blocking Release'.
Projects
None yet
Development

Successfully merging a pull request may close this issue.

3 participants