Is there a Windows equivalent of the Setuid?

I want to give a program the rights of the user executing it. Is there an equivalent of the Setuid on Windows (preferably Windows 7 or at least Windows post-XP) ?

What if I want the program to have more rights than the user executing it ? (For example, I want the program to write to Program File whereas I don't want the user to be able to).

Solution 1:

Short answer, you don't need to do anything to make a program run with the rights of the user that spawned it. This is standard for windows systems.

To force a program to execute as an entirely differant user, as SetUID does, Microsoft has provided the Runas command, which you can use to invoke an executable under a differant users credentials.

Additionally, on UAC enabled systems like Windows 7, you can hold Shift + Right-click on an executable, to run the program under a differant user, and invoke that users administrator rights if required.

Please note, the answer below is related to the original question about Sticky.

To directly answer your question, Yes and no. One can emulate the function, but the application is entirely differant.

I think you may be confusing the Sticky bit with the other special unix permissions SetUID and SetGID, both of which affect how applications execute in relation to the user invoking the process, but Sticky does not.

Sticky will allow no user, other than root or the Owner-user, to delete or rename a file, even if the user has Write rights, and can thus edit the file.

In the Advanced Permisions window (from an objects Properties -> Security tab -> Advanced), you can Add or Edit permissions for the CREATOR OWNER "user" and grant them permissions Delete and Delete subfolders and files. Then for every other entity in the ACL, revoke (but don't Deny) those same permissions.

This will allow all users with write to create/edit any file, but only the file owner can delete it.

Note that this approach also has the same flaw that Sticky has: that any user with edit rights, may overwrite the file with 0B, which is conceptually simmilar to deleting the file (many argue that its as-good-as...).

good luck.

Solution 2:

In Windows you cannot run a program as a different user without knowing the target user's password or saving this information on the machine once.

A program on Windows will by default always execute using the current user's privileges. This also applies to what folders or settings the program can then access. These settings can be changed in the Security tab of a program or folder.

You can start a program with another user (if you for example hold SHIFT + right-click then select Run as different user or just Run as administrator) to grand it elevated rights of another user that has admin rights on the machine.

Using the runas CMD command can also achieve this and can be set in a shortcut to automate the login

Documentation here

An example:

runas /user:.\localadmin /savecred notepad.exe

The /savecred parameter tells the command that the user password has already been saved on the machine and won't require a password at run. The password must first be stored in the Credential Manager in Control Panel.

Note that this will also load the program using the other user's profile. A program that saved settings in AppData for example will load them from the user that executed the program.

Windows Services however can run as a different user. This can be done in

Services.msc console > select Service > Properties > Log On