Re: Can't set a DACL on a folder that was NULLed.
- From: "Paul Baker [MVP, Windows - SDK]" <paulrichardbaker@xxxxxxxxxxxxxxxx>
- Date: Tue, 4 Mar 2008 15:56:56 -0500
Chris,
I can't reproduce it. Here are a couple of ideas:
Try different values for the dwDesiredAccess parameter.
Try FILE_SHARE_READ or FILE_SHARE_WRITE or FILE_SHARE_DELETE for the
dwShareMode parameter.
Try adding the user to the Backup Users group and call AdjustTokenPrivileges
with SeBackupPrivilege and SeRestorePrivilege before calling CreateFile.
Paul
"Paul Baker [MVP, Windows - SDK]" <paulrichardbaker@xxxxxxxxxxxxxxxx> wrote
in message news:%23%23GZcjjfIHA.2000@xxxxxxxxxxxxxxxxxxxxxxx
Chris,
I don't think you're supposed to use NULL DACLs at all. It's what you get
if you look at the security attributes of an object that does not support
security, eg. a FAT file system. So NULL DACL is no security at all,
everyone can do everything.
Yes, removing ACEs in Windows Explorer is making it an empty DACL, which
means that everything is denied to everyone. Except the magic rule that
the owner gets READ_CONTROL|WRITE_DACL access. The Effective Permissions
page will confirm this.
I am trying to reproduc your ERROR_ACCESS_DENIED right now.
Paul
"Chris Becke" <chris.becke@xxxxxxxxx> wrote in message
news:eoiF%23ibfIHA.4760@xxxxxxxxxxxxxxxxxxxxxxx
Oops. I followed up in the wrong thread.
My mistake was assuming that removing entries using explorers securities
properties dialog was the same as setting a NULL DACL. It is not. I
suspect it sets a non-NULL but empty DACL which would not give anyone
access.
That said however, the linked MSDN article clearly implies the owner
should be able to open the folder with WRITE_DACL and READ_CONTROL - I
don't know how explorer shows the rights with an empty DACL - It clearly
succeeds where my code fails. Nonetheless, thats not the problem I needed
to fix.
My 'repair' code is correctly opening and setting a DACL back on the
previously NULL DACL folders so my real issue is resolved.
That said, I am still interested in why explorer can read the rights of
the folder, and my code, running as the owner, cant open the folder for
READ_CONTROL at all.
"Paul Baker [MVP, Windows - SDK]" <paulrichardbaker@xxxxxxxxxxxxxxxx>
wrote in message news:OZLTO5VfIHA.4260@xxxxxxxxxxxxxxxxxxxxxxx
Chris,
My theory is the same as yours - some unnoticed silliness - so I don't
know where to go next and I am hoping you can find that silliness?
Paul
"Chris Becke" <chris.becke@xxxxxxxxx> wrote in message
news:%23ZS1dqxeIHA.5280@xxxxxxxxxxxxxxxxxxxxxxx
"Paul Baker [MVP, Windows - SDK]" <paulrichardbaker@xxxxxxxxxxxxxxxx>
wrote in message news:uFVdyOxeIHA.4144@xxxxxxxxxxxxxxxxxxxxxxx
Chris,
If it's a NULL DACL, the only access is READ_CONTROL|WRITE_DACL for
the owner. I assume you are running it under the owner's account.
http://support.microsoft.com/kb/130543/en-us
There are several accounts on the debug machine, and I belive(ed) that
I could reliably choose which user I wqas debugging some code under.
However when I run the debugee under my standard user account - the
same account listed as the items owner, I am unable to open a handle to
the directory.
Is it a privilege issue? I do not understand what the documentation is
saying about privileges when FILE_BACKUP_SEMANTICS is used:
http://msdn2.microsoft.com/en-us/library/aa363858.aspx
All that I know is that all the mskb and msdn samples and help insist
that FILE_BACK_SEMANTICS is mandatory if one wishes to open a handle to
a directory using CreateFile.
I would check your parameters using a folder that is not affected to
make sure you're doing it the right way.
Ha. The code in question is the same code that previously, erronously,
removed the DACL from the folder :P
Does pszDirectory have a trailing backslash? I think it should not.
"C:\\ProgramData\\TestFolder"
You are not specifying a file sharing mode. If there is a chance
anything else has the directory open, you might consider
FILE_SHARE_READ|FILE_SHARE_WRITE and maybe even FILE_SHARE_DELETE.
0 was workinf fine in the previous run before I removed the use rights
from the folder.
Are you missing an OPEN_EXISTING parameter there?
Oops. Typo copying the code. There is in fact an OPEN_EXISTING there.
Hopefully it will be pretty easy to solve if you can reproduce it and
debug it on your development machine.
At the moment Im pretty confused. On my dev machine, I can debug the
the failure - and see that CreateFile fails and GetLastError is 5 :(
According to MSDN, as the owner, I MUST be able to open the folder for
READ_CONTROL and WRITE_DACL access.
I suspect that there is some fundamental sillyness I am overlooking.
.
- References:
- Re: Can't set a DACL on a folder that was NULLed.
- From: Paul Baker [MVP, Windows - SDK]
- Re: Can't set a DACL on a folder that was NULLed.
- From: Chris Becke
- Re: Can't set a DACL on a folder that was NULLed.
- From: Paul Baker [MVP, Windows - SDK]
- Re: Can't set a DACL on a folder that was NULLed.
- Prev by Date: Re: Can't set a DACL on a folder that was NULLed.
- Next by Date: Re: AcceptSecurityContext failing with SEC_E_INVALID_TOKEN
- Previous by thread: Re: Can't set a DACL on a folder that was NULLed.
- Next by thread: How to read secret key for a service?
- Index(es):
Relevant Pages
|
