To understand what I'm asking, it's important to distinguish between one of several uses of SUID on Unix.
I have a project that uses an executable in a user PATH that belongs to the project and which has the SUID bit. Thus, when it is executed, it is executed in the context of the owner of the file, not the caller. Thus, he has access to those things that the user does not do, and thereby these things are protected from the user by the usual file system protections. This works quite well. Plans are to move the project to a client-server architecture, but it will take some time. At the same time, how can I repeat this type of behavior on Windows systems?
Please note that project executables do not call the SETUID library, although, frankly, this would be a great opportunity to add, in my opinion, what the project does. The project does not need root privileges. The first security problem is that it must protect its own files from the user (which is just any user other than the owner of the file), and it would be very nice if he had the opportunity to switch to the "user context" to access to the file as if it were the calling user. (In this way, he could more easily determine what is appropriate for the project and what is not.)
The project is written in a combination of C and Java - a C program with a set of SUID calls Java code ...
I really want to know all such mechanisms and especially focus on those that:
- Suitable for C and Java and
- Easy to implement for non-Windows programmers and;
- Require minimum encoding unique to Windows.
If some solutions are superior, please share your thoughts on what you know in this regard.
NOTES:
- LogonUser: A plain text password is required. How can this be the answer?
- RunAs: you need to enter a password in PROMPT! ... As with LogonUser it is only worse; I do not understand how this is the answer.
windows unix
Richard T
source share