Patch for starting local workspace commands with UAC elevation

[Matthias Ludwig]

I would like to solve ab problem and have created a patch for it as basis for discussions.

The problem, it can be reproduced the following way:

- Windows with activated User Acces Control

- local workspace, wich is checked out by someon else, eg. the admin.

- you have insufficient rights to change files or the workspace metadata (.svn folder)

- starting a TortoiseSvn-Operation by shell context menu, wich needs to write someting to the workspace or workspace-meta-DB (.svn-Folder)

Result:

operations fails with error messages. (for example "Can't add files to ignore list") 

Starting explorer in admin mode does not help. Shell context menu commands will nevertheless run in lower prileges. I'm not sure why, but I guess this is because TortoiseSvn-Shell starts TortoiseSvnProc as a new proccess.

Workaround:

You can start another tool, e.g. Notepad++ in Adminstrator mode and perform the operations in its file dialog. (e.g. in "Save file as..")

But this is very annoying because this means a lot of extra clicks. If you forget it your operations fails. You might have do execute cleanup...

My Idea:

Enhance TortoiseSvn with a special mode, that executes all relevant commands with UAC elevation.

The mode can be activated in TortoiseSvn-Advanced Settings. ("ElevateUACForLocalWorkspace")

The patch file is based on the current trunk. (r29048)

[Stefan]

I'm sorry, but while your patch looks good, I won't apply it for several reasons:

• starting an elevated process from the shell can be abused
• you've marked commands that you think require elevated right, but most dialogs can start other dialogs which then might require those privileges as well. So we would have to basically start all processes elevated
• a working copy is always per user. If you're logged in as another user, create your own working copy. That's the only way you won't get into any troubles. Your 'solution' is not the right way to do this. Think about it: you run an update which creates new files. Those files then have the rights of the current user (with higher privileges), not the one who creeated that working copy. So after that, the original user will require elevated privileges as well.
• the real solution is to create separate working copies for each user

[Bruce C]

If there is a really strong need to have a single checkout for multiple users (which seems a little unusual), another option is simply to grant additional permissions, to the checkout, for the second user. Presumably the second user could then use TortoiseSVN as normal, as they'd have the necessary file permissions. From a Command Prompt (potentially elevated), this can be achieved with the cacls command. Something like the following:

  cacls checkout_root_folder /t /e /g SecondUserName:f

N.B. I'm not at a Windows PC right now to confirm the syntax or test it, so please satisfy yourself of the correctness before running it.

Hope this helps.

[Matthias]

Hi Stefan,

I  appreciate your decision, but please let me respond to your arguments and let me explain me why my requirements are useful.

> starting an elevated process from the shell can be abused

I think my modification is as secure as the concept of UAC allows it:

- If UAC is switched off or users have adminstration rights, my modification make no difference: users can always do everything. This scenario is unsecure, but it is because UAC is switched off.

- If UAC is switched on and user has the right to elevate rights: The security is by definition dependent on the user: First, the user has to enable the advanced setting - he or she needs registry modification rights.

If he or she uses TortoiseSvn then, he or she is asked with a striking UAC dialog in a grey backround if rights should be elevated. Dependent on the configuration of the user has even to enter his credentials to avoid abuse by other users. Only if he or she confirms the TortoiseProc is calles with higher rights.

- if UAC is restricted users cannot us the function, because windows will immediately decline it.

- The UAC allows users can only elevate rights if he or she is privileged to. If not he will not be able to abuse it. If yes he or she should know what he do.

- If TortoiseSvn is compromised with malware the elevated rights would give the malware higher rights. But this is general risk of letting the user decide what programs are allowed to do. This is part of the concept. User do not need use the setting.

My implementation just follows these concept by using it's mechanism. 

you wrote:

> you've marked commands that you think require elevated right, but most dialogs can start other dialogs which then might require those privileges as well   

If this dialogs are in the same process they definitely have the same rights. For this case there is no problem.

For the dialogs who are started in child processes: You're right, this processes should inherit the rights. I didn't think about that.

Inheritance of the user rights could be implemented like this:

If the process is already startet with elevated rights these child processes could be started with the same rights as well.

One can use the win-sdk functions for that: e.g. https://www.victorhurdugaci.com/using-uac-with-c-part-1, pricipal.IsInRole(WindowsBuiltInRole.Administrator)

If this helps to convince you, I would certainly implement these further steps in a proper way.

> a working copy is always per user.

You'r right in normal development process a working copy is owned by one developer. That make sense.

But I don't thing, svn restricts a working copy to one user per definition. There is no user information in the working copy at all.

Our use case is to admister web-server configuration and deployment with a high grade of automation. As you might imagine there are different OS-users with different rights for security reasons. 

For the moment I can't see any contradiction of this usage with subversions concepts. And I cant't beliefe that we are the only one who use svn in that way. I think you will make other users happy as well as you solve their problems.

I was so enthusiastic about my ideas and the implementation. Maybe you can think about your opinion.

Thanks and regards,

Matthias

[Matthias]

Hello Bruce C

Yes sure. This would be another solution.

I prefered the solution in TortoiseSvn. But if my "change request" fails I will do it that way. It's definitely possible.

Thank you