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 Stefan schrieb am Donnerstag, 7. Januar 2021 um 19:27:30 UTC+1: > 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 > > > -- You received this message because you are subscribed to the Google Groups "TortoiseSVN" group. To unsubscribe from this group and stop receiving emails from it, send an email to [email protected]. To view this discussion on the web visit https://groups.google.com/d/msgid/tortoisesvn/1c727e1a-e861-485f-84f0-7c94ceea58f1n%40googlegroups.com.
