title: What choices do I have on MS Windows platforms for the equivalent of SUID from Unix-based platforms?
body: <p>To understand what I'm asking, it's important to distinguish from among the several uses of SUID in Unix.</p>
  
  <p>I have a project that uses an executable in the user's PATH which is owned by the project and which has the SUID bit set. In this way, when it runs, it runs in the context of the file's owner, not the calling user. This way, it has access to things that the user does not, and thereby these things are protected from the user by normal file system protections. This works reasonably well. Plans are to move the project to a client-server architecture but that's going to take some time. In the mean time, how can I replicate this type of behavior on Windows systems? </p>
  
  <p>Note that the project's executables do not call the SETUID library call though, frankly, that would be a great feature to add, in my opinion, given what the project does. The project does not need system root privileges. It's first security concern is that it needs to protect its own files from the user (which is simply any user other than the file owner) and it would be very nice if it had the ability to switch to "user context" to access the file system as if it were the calling user. (In this way, it could more easily determine what is OK for the project to touch and what is not.)</p>
  
  <p>The project is written in a combination of C and Java - a C program with SUID set calls the Java code...</p>
  
  <p>I am keen to know all such mechanisms, and am especially focused on those which are:</p>
  
  <ol>
  <li>Suitable for C and Java, and;</li>
  <li>Easy to implement for non-Windows programmers, and;</li>
  <li>Require minimal coding unique to Windows.</li>
  </ol>
  
  <p>If some solutions are superior, please share your thoughts on whatever you are aware of in this regard.</p>
  
  <p>NOTES:</p>
  
  <ol>
  <li>LogonUser: Requires a password in plain text. How can that be an answer?</li>
  <li>RunAs: Requires password be entered at PROMPT! ...As with LogonUser only worse; I don't see how this is an answer.</li>
  </ol>