I need to access the 'System Volume Information' folder (if exists), which is by default only made available to the System account. I know it is possible to take ownership of the directory in order to get access (assuming I'm logged in as member of administrators) - but I think this approach would seem a little too rough, as that would alter the system rather than scanning it.
I also know that this approach is possible programming a Service module, but again, the application must be simple.
I have looked up a couple of things, and come to the understanding, that is is possible to assign a different security descriptor for a thread running the scan, while informing the GUI of the results.
To the question: How is that possible? Am I forced to make two applications or alter the account rights of the folder before entering? I am completely in the blue about this.
Thanks for a great product - It may not have helped me yet, but given me some understanding of how ACL's work.
However, My need is opposite, a user scans his system, but a thread needs to be spawned impersonating the System account in order to access the NTFS "System Volume Information", where the _restore folders are found.
Am I looking the wrong place to solve this issue?
What approach would you be looking for?
When it is easy to make a service, install it and run using the system account, I cant believe it is this tough to do within a single application?
The easier way might be to teach your app how to alternatively behave as a service. Then when you start your app as a normal app and when you have admin rights, you can simply create a service based on your own exe file. Let the service do it's task, then stop and delete the service again.
Both solutions sound kind of ugly to me.
Alternatively you could store the current ownership and DACL of the folder, take ownership, set a new DACL, and finally undo all your changes. I believe you can also restore the old ownership. This all should be doable by using madSecurity I think. madSecurity wouldn't help with the first two ("ugly") solutions listed above.
Well, that of cause would look a bit ugly, if the program was to run in console mode and the user could cancel the task using CTRL+C, the exit would not be gracefull. Then I cant see how I can guarantee, that the ownership remains - unless of cause I make it into a windows-based application with a nice big cancel button on it.madshi wrote: Alternatively you could store the current ownership and DACL of the folder, take ownership, set a new DACL, and finally undo all your changes. I believe you can also restore the old ownership. This all should be doable by using madSecurity I think. madSecurity wouldn't help with the first two ("ugly") solutions listed above.
Reason is also, that I would like to avoid size-issues using the huge windows/forms units (I often rewrite a smaller windows unit for kernel references).
I think though, I shall try your suggestion using the LogonUser method, just to play around with it. Once obtaining the token, I can always hand it to a thread, in attempt to change its security context. I'll come back later with an answer to all this.
And I ussually trust people who knows their stuff, I guess I'll run for your recommended approach then (Chaning owner and adding privileges), however I think I can make a solution that would solve the gracefull exit problem.madshi wrote:As I said, LogonUser usually only works inside of system/service processes, unfortunately.
To whomever might find it usefull, I can still make a shell console application, load the scansvc.exe as a resource, deploying it on execution (Created as a temporary file - automatically deleted upon exit (gracefull or not)). A service cannot be halted ungracefully by anythnig but an EndProcess call. I can though, make the process execution dependant of the calling thread. (This way I may also be able to pack/encrypt the executable to prevent most reverse engeniering). I guess that would be gracefull enough for me
Thousands of thanks for your help. If you are interested, I can state a reply later with the final result.