Welcome to Vista Banter. You are currently viewing our boards as a guest which gives you limited access to view most discussions, articles and access our other FREE features. By joining our free community you will have access to ask questions and reply to others posts, upload your own photos and access many other special features. Registration is fast, simple and absolutely free so please, join our community today! If you have any problems with the registration process or your account login, please contact contact support. |
|
Vista Administration, Accounts and Passwords Queries, comments and issues relating to the administration of Windows Vista. (microsoft.public.windows.vista.administration_accounts_passwords) |
|
LinkBack | Thread Tools | Display Modes |
|
|||
Full Control to Users programmatically
That's interesting. Thanks. I assume that needs to be
run by Admin., but it seems like incorporating such a thing into setup would be a good approach. (Hopefully shelling to cacls rather than invoking script.) I'm inclined to partly agree with the rather vociferous Vista MVPs who are piping up he People should be informed and given an option about changing their settings. But your idea makes a lot of sense to me for adapting a Vista setup. Rather than moving eveything to All Users App. Data (which doesn't make much sense) maybe a checkbox option could be provided in setup. Something like: |_| Make this program fully available to all users. I created a function: Public Function SetUsersPermission(strFolder As String) As Integer 'Call this function when a new folder is created in Coordinator Folder 'to give a Full Access to Users Dim objShell As Object Dim intRunError As Integer On Error Resume Next intRunError = 1 'in case of error that value will be returned Set objShell = CreateObject("Wscript.Shell") 'objShell.Run returns 0 if success intRunError = objShell.Run("cmd /c cacls " & strFolder & " /e /g Users:F", 0) SetUsersPermission = intRunError End Function I call it every time I'm creating a new folder which is going to be accessed by my program to save there some file. |
|
|||
Full Control to Users programmatically
I may have come on a little strong. Yes, many programmers have used poor
practices in the past. This is the reason we are now stuck with uac in an attempt to secure Windows. You should create a manifest for your installation program and change the programs to work with the shims for legacy applications in Vista. This will get your program working relatively quickly and allow you time to rewrite it properly. http://msdn2.microsoft.com/en-us/win.../aa904987.aspx -- Kerry Brown Microsoft MVP - Shell/User http://www.vistahelp.ca "vovan" wrote in message ... I'm doing it for the folder with my program. What is wrong with this? I said I do not give permission to the entire Program Files folder. What is the difference if I move my program to different location and will allow to access its folders there? What about a lawsuit for such companies like Adobe with their Photoshop, which stores temp files in its folder. I did not test it on Vista yet, but I think there might be some problems with permission too. I'm looking for the fastest way to adopt my program to Vista for now. Later I will think about the need to redisign it. Now my clients are going to by new machines with Vista. I tested my program on it and many features do not work. So, what is the best way from your point of view to give them the ability to use my program on Vista. Ask them to wait until I redesign everything? I also woud ask if there is anybody else as stupid as me who did not have any problem with security before, but with Vista has them. Or it's just me? Everybody else knew all the time that it's a bad idea to install his (her ) program in Program Files folder. Everybody always knew that it's a bad idea to store temporary files in its program folder. Everybody always knew that Microsoft is going to change their security phylosophy. Only I did not know anything. Thank you Vovan "Kerry Brown" *a*m wrote in message ... Why would you want to risk doing this? What will happen when some user finds out you modified their system needlessly and lowered their security. It is their computer not yours. Are you so arrogant that you think your program can do whatever it wants to someone else's computer or are you just too lazy to lean how to do things properly? You will potentially alienate your customers at best and possibly set yourself up for a lawsuit at worst. Vista is here. Learn to program for it. -- Kerry Brown Microsoft MVP - Shell/User http://www.vistahelp.ca "vovan" wrote in message ... I created a function: Public Function SetUsersPermission(strFolder As String) As Integer 'Call this function when a new folder is created in Coordinator Folder 'to give a Full Access to Users Dim objShell As Object Dim intRunError As Integer On Error Resume Next intRunError = 1 'in case of error that value will be returned Set objShell = CreateObject("Wscript.Shell") 'objShell.Run returns 0 if success intRunError = objShell.Run("cmd /c cacls " & strFolder & " /e /g Users:F", 0) SetUsersPermission = intRunError End Function I call it every time I'm creating a new folder which is going to be accessed by my program to save there some file. Vovan "mayayana" wrote in message hlink.net... I found some way (using Windows script) to give Users full control on "C:\Program Files\My Program", not on entire "C:\Program Files\". Just on my folder. It looks like adjustment will take much less time than full redesign. What is wrong with this approach? That sounds like a good idea to me. How do you achieve that? (My best idea for a solution so far is a note saying something like: "If you have the misfortune to be using Windows Vista, and you want to use this software, then you will need to give yourself permission to fully use your PC." |
|
|||
Full Control to Users programmatically
Look guys,
It has *never* been acceptable to MODIFY files in Program Files. Just because it WORKED in earlier version of Window doesn't mean it was *OK* to do so! The folder that your app is installed in inside program files is not YOUR FOLDER ... it is a SYSTEM FOLDER. In fact, NONE of the folders that your app creates or the files your app creates are YOUR FILES. They are your user's files. You app only has whatever permissions to these folders/files as Windows and your users want your app to have to them. It is NOT up to your app what access it gets. Please, understand this ... "Program Files" is for static, unchanging, read-only files that are necessary for your program to run. *All* other content is stored in PER-USER locations. Most programs have gotten this right ... some haven't until ... sorry you haven't learned this before, but NOW is the time! And it is your fault here for not learning how to do things correctly, don't blame Microsoft or your poor users here. Hate to break the bad news . It is *never* acceptable to change security on system files to get your program to run. -- - JB Microsoft MVP - Windows Shell/User Windows Vista Support Faq http://www.jimmah.com/vista/ |
|
|||
Full Control to Users programmatically
Even Agent has changed with the 4.2 release to move, by default - but it
asks, the user files to your user directory. I haven't looked yet, but I suspect that the 'all users' area might be the place to put files that must be shared with all users and can be modified by any user. "Jimmy Brush" wrote in message ... Look guys, It has *never* been acceptable to MODIFY files in Program Files. Just because it WORKED in earlier version of Window doesn't mean it was *OK* to do so! The folder that your app is installed in inside program files is not YOUR FOLDER ... it is a SYSTEM FOLDER. In fact, NONE of the folders that your app creates or the files your app creates are YOUR FILES. They are your user's files. You app only has whatever permissions to these folders/files as Windows and your users want your app to have to them. It is NOT up to your app what access it gets. Please, understand this ... "Program Files" is for static, unchanging, read-only files that are necessary for your program to run. *All* other content is stored in PER-USER locations. Most programs have gotten this right ... some haven't until ... sorry you haven't learned this before, but NOW is the time! And it is your fault here for not learning how to do things correctly, don't blame Microsoft or your poor users here. Hate to break the bad news . It is *never* acceptable to change security on system files to get your program to run. -- - JB Microsoft MVP - Windows Shell/User Windows Vista Support Faq http://www.jimmah.com/vista/ |
|
|||
Full Control to Users programmatically
On Sat, 10 Feb 2007 10:46:32 -0800, "Kerry Brown"
*a*m wrote: in Why would you want to risk doing this? What will happen when some user finds out you modified their system needlessly and lowered their security. It is their computer not yours. Are you so arrogant that you think your program can do whatever it wants to someone else's computer or are you just too lazy to lean how to do things properly? You will potentially alienate your customers at best and possibly set yourself up for a lawsuit at worst. Vista is here. Learn to program for it. -- Kerry Brown Microsoft MVP - Shell/User http://www.vistahelp.ca Ha ha ha. That wouldn't normally be so offensive but for this: http://hairyears.livejournal.com/101843.html and this: http://www.cs.auckland.ac.nz/~pgut00...ista_cost.html microsoft has made the decision that your computer is no longer yours so your little rant looks really silly in light of the above ~VERY WELL DOCUMENTED~ articles. So blow it out your bilge pipes there mister mvp brown or whoever you are. If anything, the class action lawsuits are just beginning to brew so please stay posted for further developments. I thought it was my computer and not theirs but apparently they changed the rules and forgot to tell everyone which is not fair. Are they so arrogant that they think their OS can do whatever it wants to anyone's computer or are they just too lazy to lean how to do things properly? They will potentially alienate their customers at best and possibly set themselves up for a lawsuit at worst. I just can't wait until Paul Clement has a go at this. Let's hear something cogent for a change, mister Paul, please. --- This posting is provided "AS IS" with no warranties and no guarantees either express or implied. Stefan Berglund |
|
|||
Full Control to Users programmatically
Look guys,
It has *never* been acceptable to MODIFY files in Program Files. Just because it WORKED in earlier version of Window doesn't mean it was *OK* to do so! We all know Microsoft's party line. What Microsoft decides is "OK" is not particularly relevant here. They designed a product. They sell it. Now people writing software need to decide the best way to deal with it. You know perfectly well that Program Files has always been where most software worked out of until recently. (After all, what point would there be to VB's App.Path property if nothing there could be accessed? And very few people other than corporate lackeys on workstations run XP as anything other than admin. It's not as simple as just "going along with the plan". Even if you think that Microsoft's general plan makes sense, it's only geared toward corporate users. Home and small office users want functionality...they don't want frivolous warnings...and they usually don't want settings changing between users. So the challenge is to work out the simplest way to seamlessly allow people to run software that way, as unrestricted for all users. I think that everyone wants to try to do that in a standard way that makes it easy for users, but the options in Vista for all-user-accessible software seem to come down to either cutting the security in Program Files or moving everything to All Users App Data. There doesn't seem to be an option that's in accord with what MS officially defines as "OK". |
|
|||
Full Control to Users programmatically
snip
We all know Microsoft's party line. What Microsoft decides is "OK" is not particularly relevant here. They designed a product. They sell it. Now people writing software need to decide the best way to deal with it. Nonsense. You are writing software that BUILDS ON TOP of Windows. You are REQUIRED to follow the specifications of that system ("What Microsoft decides is 'OK'"), whether you like it or not. If you find some way to do something that is "out of spec" (such as writing to Program Files) that works (as it did in XP when the user was admin), it is AT YOUR OWN PERIL that you perform such behavior. The fact that a non-compliant behavior may have worked before certainly does not make the behavior OK, and definately doesn't justify you TRYING TO FORCE IT TO WORK when Windows changes. You do not "work around Windows" by subverting it! Software that does this is called 'malware'. You know perfectly well that Program Files has always been where most software worked out of until recently. Rediculous. "My Documents" and other special shell locations have been set up for application's usage SINCE WINDOWS 98. Only broken apps saved state to Program Files. The current Windows filesystem security structure has been in place with little modification since Windows 2000. It is now 2007. This isn't a big secret - look on MSDN and there is MUCH DETAIL on each system location in Windows, what goes there, who can access it, and how much access they have. (After all, what point would there be to VB's App.Path property if nothing there could be accessed? The stuff there can be accessed. You just can't write to it. There are API's to determine what access you can get to files; Use them And very few people other than corporate lackeys on workstations run XP as anything other than admin. Your point here is that "well, since most people are admin, why should I worry about following the spec... I'll just do it this non-compliant way, since it will work most of the time". Again, the problem here is that your are NOT FOLLOWING SPEC, and if you release code that doesn't follow spec you run the risk of Microsoft breaking your program every time they release a hotfix, service pack, or new version. Well, it finally happened ... you bet and lost ... now you have to deal with it. In Windows Vista, ALL non-admin programs are running in a limited account, even if the user that started them is an admin. Non-administrative applications that follow spec are not affected by this change. Administrative programs only need to be changed to prompt the user for permission, and they will work fine. Non-administrative applications that DO NOT follow spec MUST BE MODIFIED TO CONFORM to the already well-published spec in order to run on the new OS. It's not as simple as just "going along with the plan". Of course it is. Your application must interface with Windows the way Microsoft requires it to. Even if you think that Microsoft's general plan makes sense, it's only geared toward corporate users. Home and small office users want functionality...they don't want frivolous warnings...and they usually don't want settings changing between users. So the challenge is to work out the simplest way to seamlessly allow people to run software that way, as unrestricted for all users. Ignoring the fact that you are making a wide, sweeping claim about ALL USERS which, besides being unsubstantiated, cannot possibly be true... The reality of the situation is: 1) The people that only want to use ONE ACCOUNT, will only USE one account. 2) The people that want to use MORE THAN ONE account, will. In *ALL* cases, your app WORKS CORRECTLY if it ONLY writes data to per-user locations. You have NO REASON to store data in Program Files. I think that everyone wants to try to do that in a standard way that makes it easy for users, but the options in Vista for all-user-accessible software seem to come down to either cutting the security in Program Files or moving everything to All Users App Data. There doesn't seem to be an option that's in accord with what MS officially defines as "OK". It's easy ... store data in per-user locations . In Windows, each user account is completely isolated from the next. One user cannot mess with another user's or the system's stuff. Only ADMINS can do that. Any program that wants to do this MUST be allowed to run by an admin, or must be running as part of the operating system (like a windows service does). This is the way Windows is architected, and so your app MUST follow this design pattern. If your program has a legitimate need to be mucking around in Program Files, then it is an administrative program, and must require admin permission from the user before mucking around with those files. Or, if the chunk of your program that is needing access to the program files folder is really an extension to the OS, then it needs to be written as a Windows Service. The days of Windows ME where applications did whatever the heck they felt like at the expense of stability, user control, and security are over. Sorry . -- - JB Microsoft MVP - Windows Shell/User Windows Vista Support Faq http://www.jimmah.com/vista/ |
|
|||
Full Control to Users programmatically
What does DRM have to do with any of the discussion in this thread?
-- Kerry Brown Microsoft MVP - Shell/User http://www.vistahelp.ca "Stefan Berglund" wrote in message ... On Sat, 10 Feb 2007 10:46:32 -0800, "Kerry Brown" *a*m wrote: in Why would you want to risk doing this? What will happen when some user finds out you modified their system needlessly and lowered their security. It is their computer not yours. Are you so arrogant that you think your program can do whatever it wants to someone else's computer or are you just too lazy to lean how to do things properly? You will potentially alienate your customers at best and possibly set yourself up for a lawsuit at worst. Vista is here. Learn to program for it. -- Kerry Brown Microsoft MVP - Shell/User http://www.vistahelp.ca Ha ha ha. That wouldn't normally be so offensive but for this: http://hairyears.livejournal.com/101843.html and this: http://www.cs.auckland.ac.nz/~pgut00...ista_cost.html microsoft has made the decision that your computer is no longer yours so your little rant looks really silly in light of the above ~VERY WELL DOCUMENTED~ articles. So blow it out your bilge pipes there mister mvp brown or whoever you are. If anything, the class action lawsuits are just beginning to brew so please stay posted for further developments. I thought it was my computer and not theirs but apparently they changed the rules and forgot to tell everyone which is not fair. Are they so arrogant that they think their OS can do whatever it wants to anyone's computer or are they just too lazy to lean how to do things properly? They will potentially alienate their customers at best and possibly set themselves up for a lawsuit at worst. I just can't wait until Paul Clement has a go at this. Let's hear something cogent for a change, mister Paul, please. --- This posting is provided "AS IS" with no warranties and no guarantees either express or implied. Stefan Berglund |
|
|||
Full Control to Users programmatically
"mayayana" wrote in message
.net... Look guys, It has *never* been acceptable to MODIFY files in Program Files. Just because it WORKED in earlier version of Window doesn't mean it was *OK* to do so! We all know Microsoft's party line. What Microsoft decides is "OK" is not particularly relevant here. They designed a product. They sell it. Now people writing software need to decide the best way to deal with it. You know perfectly well that Program Files has always been where most software worked out of until recently. (After all, what point would there be to VB's App.Path property if nothing there could be accessed? And very few people other than corporate lackeys on workstations run XP as anything other than admin. It's not as simple as just "going along with the plan". Even if you think that Microsoft's general plan makes sense, it's only geared toward corporate users. Home and small office users want functionality...they don't want frivolous warnings...and they usually don't want settings changing between users. So the challenge is to work out the simplest way to seamlessly allow people to run software that way, as unrestricted for all users. I think that everyone wants to try to do that in a standard way that makes it easy for users, but the options in Vista for all-user-accessible software seem to come down to either cutting the security in Program Files or moving everything to All Users App Data. There doesn't seem to be an option that's in accord with what MS officially defines as "OK". Who's computer are you writing the program for yours or your customers? If it's yours do whatever you want. If it's a customers then if you want to keep the customer you don't mess up their computer. Windows programmers are lazy and have learned many bad habits over the years because it worked. It no longer works. There are shims in Vista to allow you to quickly get your program working. Once you have it working rewrite it to work properly. Note that anyone who did this from the start wouldn't be having these problems. If you program around the OS your program will break again and again as service packs and new versions of the OS are released. If you hard code paths you will always have problems. You should be querying environment variables which have remained consistent since NT. You should expect that your program doesn't have complete control of the computer as in most OS' this is true. You should expect that your program may be used by multiple users and may be networked. There is a reason Microsoft officially defines "OK". It's to make sure programs run as the OS is updated. Take a look at a user profile on an XP computer and see where most programs store their settings and data. If you had done this using environment variables to get the path you wouldn't be having problems now. What it comes down to in the end is how many times do you want to fix your program. Do it right and it won't break. Do it wrong and it will break inconveniencing you and your customers. -- Kerry Brown Microsoft MVP - Shell/User http://www.vistahelp.ca |
|
|||
Full Control to Users programmatically
"Jimmy Brush" schrieb im Newsbeitrag ... [writing to Program Files] You do not "work around Windows" by subverting it! Software that does this is called 'malware'. So MS-Office (prior 2007), MS VisualStudio (.NET too), etc. is malware - good to know. Again, the problem here is that your are NOT FOLLOWING SPEC, ... Ok, that is one point, but as everybody knows, exactly following a SPEC in daily work comes near to go on strike. That's one reason why people in their work always follow a 'common practice', wich is (more or less) based on the SPECs. The OS-Vendor himself is responsible for great parts of those "practical standards". And if I look into \Program Files\Microsoft Office\Office\... I find e.g. a 'System.mdw' there, wich stores security-related things regarding the usage of Accesss-Databases (for all Users). From my point of view there's no reason, to blame any developer who was following MSs-"practical standards" and not MSs- "SPECs" (SPECs can be changed the same way as practical standards - but normally one is more secure, if he "does it the same way as the vendor"). Now MS decided, to go the hard route (following their own SPECs), wich means they have to pay the price (as well as all other adopters of their earlier common practice) - e.g. VS 2005 had/has many problems to run under Vista. It's easy ... store data in per-user locations . No that's not so easy. Imagine an app (e.g. a FamilyAddresses.exe with a 'CommonAddresses.mdb') for wich every user of the machine (the whole family) has to have Read *and* Write-Access. Where should the file 'CommonAddresses.mdb' has to be placed? In "AllUsers"?! - ok - but then only the owner (creator) of this file has write-access to it. This means, either FamilyAddresses.exe has to run under an Admin-Account or an Admin allows write-access to this single file in (and for) "AllUsers" explicitely. Olaf |