I get so frustrated with some of the hurdles that one must overcome for successful Windows deployment. One in particular is folder and file permissions Currently my main application requires data files located on a server and all users need read/write permissions. I set permissions in my installer (Innosetup) and I set both folders and files as users-full.
I get so frustrated with some of the hurdles that one must overcome for successful Windows deployment. One in particular is folder and file permissions Currently my main application requires data files located on a server and all users need read/write permissions. I set permissions in my installer (Innosetup) and I set both folders and files as users-full.
But it seems this is still not adequate. I've noticed on a couple of different remote assistance calls that any given customer could in fact have any number of groups created whether they be domain groups or user groups or what have you.
I need a bullet proof setting.
What do you do?
Will "everyone-full" do it?
But it seems this is still not adequate. I've noticed on a couple of different remote assistance calls that any given customer could in fact have any number of groups created whether they be domain groups or user groups or what have you.
I need a bullet proof setting.
What do you do?
Will "everyone-full" do it?
You set it on the files and the directory, but what about the file share?
ReplyDeleteThat was another question - Im not certain how in Innosetup so I'll look around.
ReplyDeleteCreate a folder in "my documents" from the installer, then store ALL files there. This is how winapi was designed from Vista and beyond. And it's the only place where you have R/W access as we are used to on older windows, like XP etc..
ReplyDeleteAlso, put your data files (downloaded or otherwise) in "program data/company/product" and install your files into "program files" as per usual. By asking windows for these paths, your app will also work on terminal server etc.. But you need to keep track of 3 folders from within your program. Give me a shout for some pre-made code for this, it's very simple once you see an example
ReplyDeleteThanks Lennart Aasenden but my documents doesn't cut it for dozens of users that need to share off of a network.
ReplyDeleteI answered while you were editing - after fighting the standards for so long I succumbed to them a few years ago so I am familiar with how things should be. But at the same time, frequently there is a need to step outside of the standard. The biggest problem is the fact that multiple users are needing read/write access to the same files over a network.
Thanks again, I appreciate your comments and offer of assistance.
Ah, sorry. I guess you already know about all this (e.g "all users" folder)- just trying to be helpful. I go bananaz myself at this, especially when you have a computer under AD which you access through citrix :P
ReplyDeleteThings get complicated quickly when you begin dealing with so many variable.
ReplyDeleteI hear you, best of luck though!
ReplyDeleteLars Fosdal I found some code that looks like it at least compiles with Innosetup:
ReplyDeleteConst
FILE_SHARE = 0;
MAXIMUM_CONNECTIONS = 25;
function CreateShared(const Path, Name, Description : string):Integer;
var
FSWbemLocator: Variant;
FWMIService : Variant;
FWbemObjectSet: Variant;
begin
FSWbemLocator := CreateOleObject('WBEMScripting.SWBEMLocator');
FWMIService := FSWbemLocator.ConnectServer('', 'root\CIMV2', '', '');
FWbemObjectSet := FWMIService.Get('Win32_Share');
Result:=FWbemObjectSet.Create(Path, Name, FILE_SHARE, MAXIMUM_CONNECTIONS, Description);
end;
My only question is is this likely to function on XP and up?
Thanks for your tip about the sharing.
Patrick Hughes have yo considered to use NSIS installer instead? not cannonical installer, but works!
ReplyDeleteHadn't known about NSIS Heinz Toskano it looks interesting perhaps for further investigation. For now I'm "invested" with time in Innosetup - if you catch my drift.
ReplyDeletePatrick Hughes As I view it, a tool that works is better than one that didn't, even if it's older. Also any time invested on a working tool, worths it if it relieve you from any pain. BTW NSIS is very easy to understand and has a lot of examples to start with.
ReplyDeleteIf you're already setting permissions on Users, and that's not enough, there's not much more you can do. You can check for the presence of a domain and use Domain Users instead of Users, which should help. There's also the Authenticated Users security principal, but that's even more open. The safest thing to do is inherit your security from the parent though and make opening up to Domain Users/Users an opt-in during installation. Anyone with more complex security schemes than that needs to deal with what they have. Customers with complex security schemes (and the skill to administer them) are likely to be unamused when they find you've cracked a share wide open to the entire domain (or wider, if you're using something like Authenticated Users or, worse yet, Everyone).
ReplyDeleteIf you wanted to be /really/ security conscious, you could create a custom group for the users of your application and prompt during installation about users that can be added. Then you'd open up the permissions for that file share to that particular group.
I recomment you write some scripts and just use the Windows command line tools to set permission. lcacls is the modern version replacing the XP era cacls.exe
ReplyDeleteThank you everyone that responded - some good suggestions here.
ReplyDeleteI'm a little embarrased to say I may have over-reacted. A customer had a problem during an install and rather than aborting he proceeded. My installer attemps to shut down all instances during an "update" and some instances did not shut down. The executable was somehow corrupted after the ignore and then failed to start with a permissions error.
Use a command line tool like SetACL to modify access rights to directories.
ReplyDelete