Hi,
I have a NTFS volume with ~300,000 folders and files on it. Using C/C++, I need to change the effective permission from read-only to writable QUICKLY. I have written some code using SetNamedSecurityInfo() against the root directory, which worked, however, I was dismayed to find that using the ACE flags CONTAINER_INHERIT_ACE | OBJECT_INHERIT_ACE caused the new ACE to be propagated immediately, instead of calculated when the subobjects were accessed. It took about 15 minutes for SetSecurityInfo() to return. Here is my test code:
int main(int argc, char* argv[])
{
#define THE_PATH "g:\\"
PSECURITY_DESCRIPTOR SecurityDescriptor = NULL;
PACL pDacl;
DWORD status;
PSID psidOwner;
PACL NewAcl = NULL;
time_t seconds;
DWORD InheritFlag = CONTAINER_INHERIT_ACE | OBJECT_INHERIT_ACE;
ACCESS_MODE option = GRANT_ACCESS;
EXPLICIT_ACCESS explicitaccess;
seconds = time(NULL);
status = GetNamedSecurityInfo(
THE_PATH,
SE_FILE_OBJECT,
DACL_SECURITY_INFORMATION|
&psidOwner,
NULL,
&pDacl,
NULL,
&SecurityDescriptor
);
BuildExplicitAccessWithNam
&explicitaccess,
"Users",
FILE_ALL_ACCESS,
// FILE_GENERIC_READ,
SET_ACCESS,
InheritFlag
);
status = SetEntriesInAcl(
1,
&explicitaccess,
NULL,
&NewAcl
);
status = SetNamedSecurityInfo(
THE_PATH,
SE_FILE_OBJECT,
DACL_SECURITY_INFORMATION ,
NULL,
NULL,
NewAcl,
NULL);
seconds = time(NULL) - seconds;
printf("It took %d seconds.\n", seconds);
if (ERROR_SUCCESS != status) {
printf( "SetNamedSecurityInfo Error %u\n", status );
}
if(SecurityDescriptor) LocalFree(SecurityDescript
return 0;
}
Some background on my situation: The volume in question is essentially a database extract, which is distributed on a hard drive to my customers. The customers are frequently in situations where a network connection is unavailable, so the hard drive provides them the data they need without requiring a network connection. Also provided is a util for synchronizing their copy with a master copy, which is used when a network connection is available. We have run into problems where a user accidentally drags one of the folders into another folder, which disturbs the structure expected by the update util. Hence the desire for this data to be read-only, except when the util is running. The owner of all the files/dirs is the group Users, so the customers will not have problems running a program that changes permissions on objects on this volume. What this boils down to is that we are not concerned with setting protections that can't be changed with the Explorer Security dialog, merely preventing accidental moves/deletes.
I have thoughts on how I might solve this:
- Are inherited ACEs always propagated immediately? If not, what code is required for this behavior?
- I have seen hints that XP supports mounting NTFS volumes read-only, but no code samples on how this is accomplised. Is this a flag that can easily be set without unmounting the volume? My volume is actually encrypted using PGPdisk, so if I can't set a flag on an already mounted volume, I doubt I could get this approach to work.
Other suggestions?
Thanks
This Question has been solved and asker verified All Experts Exchange premium technology solutions are available to subscription members.
Experts Exchange has been collecting answers to technology questions since 1996…3 million and counting! If you have a question, chances are we already have your answer.
If you can't find the exact answer you're looking for, ask our exclusive community of 50,000 experts. You’ll get a personalized answer from a trusted professional.
Thousands of free tech tips, tricks, how-to’s and tutorials are available in our peer reviewed articles section. See for yourself how smart our experts are, no login required.
Save solutions to your questions, answers you’ve discovered through searching plus helpful articles in your personal knowledgebase for easy future access.
Access the answers to your technology questions today.
30-day free trial. Register in 60 seconds.
Members of the expert community talk about why the experience at Experts Exchange is different than what you will find anywhere else.
Try it out and discover for yourself.
30-day free trial. Register in 60 seconds.
Join the community of experts here and help other tech pros by answering question in your area of expertise. You can earn FREE access to all Experts Exchange's premium features and resources.
to provide the credentials when running as a service, simply set the service up to run under those credentials, same as a scheduled task, if you want to use the "createprocess" method then there is just a little of programming that has to happen, but ... I think it is much BETTER to run it as a service, if the user must run a program, then the program should just start the service (which will automatically stop when syncronize is complete), and then just leave the Syncronize service as run manually
Well, what happens now is that when the person runs the utility they are creating the process under thier user ID, I am suggesting a different user ID be created for the syncronization process and that user ID should be the only one that has sufficient rights to the local hard drive, you can either have the user supply them in a password box at the time of run (added security) or have them set up in the process read from some encrypted source on the computer, the create process is a simple function callable from just about every language, and in C, you have the added benefiet of being able to provide SPI credentials
Kavar,
Your solution will certainly work, but I was hoping not to have to create an additional account and manage a password. There is a certain amount of corporate bureaucracy involved with accounts that are not regular user accounts, and I prefer to avoid it if possible.
I am new to Experts Exchange. Can I leave the question open for a few days to see if other approaches are suggested?
Thanks
sure, But as far as quickly changing security descriptors.... there are several problems involved the first being, depending on the layout, there may be litterally 1000s of ACLs to change, additionally, the right to change those ACLS must exist and therefore, you are inherently running this from an account that CAN change the data even if you don't want to ...
well it "doesn't" if the children have the inherritence flag set, and do not have thier "own" acl, so if the only change is at the root, it will return immediately, the problem is most of the time, this is not the case.... and when you say "I", I assume that means some program... if the program is running under special credentials then your are back where we started, if the program is not running under special credentials, then how did you have rights to change the ACL from Read to modify?
OK, I image the disks before they are distributed. Part of my planned imaging process is to change the owner of the volume root to the group Users, and to set all the child files/dirs so that their only ACL is what they inherit from the root. Any authenticated user is a member of the group Users, so any of my customers will have permission to change permission, as they are members of the owning group. When I check the Security dialog in Explorer, it does indicate that the only ACL the children have is inherited from the parent. Then, using the code in my original post, I change the root from FILE_ALL_ACCESS to FILE_GENERIC_READ, or vice versa, and SetNamedSecurityInfo() takes a --long-- time. Using Sysinternals Process Explorer verifies that every child is being accessed, which I must assume is to propagate the ACL. So, either I'm doing something wrong in my code (very possible), or that's just how it works.
The filesystem is currently 60 GB, and is about 2/3 full, and my customers are usually thousands of miles away from our data center (high latency), and sometimes on slow links, so it's not reasonable to pull the entire filesystem. A share is out because the whole purpose of this system is make the data available when a network is not. The update process is a client server system with a database on the backend; the database stores all changes to the master copy. Each customer filesystem has a unique ID and timestamp. When the client connects, only the changes that are later than the client's timestamp are sent. This keeps the number of transactions and data sent to a minimum.
why dont you do it this way then...
create a local group on the machine that has Write priveledges to that drive (and only that group) then leave the memeber ship empty when its supposed to be right protected and add Domain users to it when it's supposed to be writable, that fixes it I am pretty sure
on error resume next
Computername=<name of local computer>
username=<local admin user account>
password=<local admin user account password>
GroupName=<local group to modify>
Set Root=GetObject("WinNT:")
Path="WinNT://" & Computername
Set ComputerObj=Root.OpenDSObj
If Err.Number=0 Then
Set GroupObj=ComputerObj.GetOb
If Err.Number<>0 Then
GroupObj.Add "WinNT://"& DomainName &"/Domain Users"
if err.number then
wscript.echo "Error Adding Domain Users to Group: " & Groupname
else
wscript.echo "Worked"
end if
else
wscript.echo "Error Connecting to Group object on computer: " & computername
End If
End If
Hmmm... I think our security group would not be too happy with a package creating local admin accounts all over the place. I would be better off with a domain level service account that has full access to the volume.
I am still perplexed by the ACL propagation issue. Can you shed some light on what the NO_PROPAGATE_INHERIT_ACE flag does in conjunction with the BuildExplicitAccessWithNam
NO_PROPAGATE_INHERIT_ACE - If the ACE is inherited by a child object,
the system clears the OBJECT_INHERIT_ACE and CONTAINER_INHERIT_ACE flags
in the inherited ACE. This prevents the ACE from being inherited by
subsequent generations of objects. This flag allows the admin to set
inheritance for only one-level down, ie. contents of the current
container.
The key being that the flag is for newly generated objects, not existing
Kavar,
I think the best approach for my app is to run the sync program as a different user. Is there a way a process to change what user it's running as, similar to setuid on Unix? If not, can a process created with CreateProcessWithLogonW interact with the logged in user's desktop? Our sync program has a GUI that provides progress status and the ability to interupt the sync.
Business Accounts
Answer for Membership
by: KavarPosted on 2006-03-08 at 07:27:35ID: 16134583
A MUCH SIMPLER approach would be to have the utitlity run under the only writable credentials. This would prevent the writes, but would allow for no changes to the NTFS drive