Full Control to Users programmatically

  • Thread starter Thread starter vovan
  • Start date Start date
V

vovan

My VB6 program is installed by setup created in InstallShield 12.
Before Vista everything was working fine.
On Vista one of the operations (replace file located in c:\program files\my
program with another file) fails - my research showed me than there is an
error 70, 'Access denied'
After I set manually Full Control to Users of that machine everything works
fine.
Any advice how to set Full Control to Users programmatically from VB6 or
from InstallShield project.

Thank you
Vovan
 
Most programs (at least before Vista) use this design.
There should be some other solution not related to change the design, I
hope.
Thanks

Vovan
 
Two things you are doing wrong here:

1) Your program can only modify Program Files during install time, from a
Windows Service, a privileged scheduled task, of if your program prompts the
user for administrator permission.

If this is part of the "setup" process for your app, it needs to be
implemented as a custom action in the setup program (marked as do not
impersonate).

Otherwise, as Jack suggested, there is probably a better way to do what you
need to do.

In Windows Vista, only programs that ask the user for admin permission can
perform administrative tasks, such as modifying files in Program Files.

Programs that do not have admin permission can only save files to the
personal folders associated with the user (such as their documents folder),
or folders set aside by the system for application storage.

2) DO NOT CHANGE SECURITY SETTINGS ON SYSTEM FILES PROGRAMATICALLY. *EVER*.
:)


--
- JB
Microsoft MVP - Windows Shell/User

Windows Vista Support Faq
http://www.jimmah.com/vista/
 
I need a full control for Users on "C:\Program Files\My Program" folder.
I had it for more than 10 years with no problem (before Vista). What's wrong
with my wish now?
It looks like you lived your live with 2 legs, you drove many cars. Now
somebody created a new kind of car requirening you to have 3 legs. And they
say that it's much better for you not allowing you to have any choice. They
are going to replace all existing models with new ones.
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?

Thank you
Vovan
 
It destroys the built-in security provided by Windows.

Changing this security setting allows ANY PROGRAM ran by ANY USER to modify
your program's files. This is unacceptable - Program Files is only to be
modified by administrators.

If you want to do this on your computer - hey, that's your choice, go right
ahead.

But you CANNOT make this choice for the users of your program - you will
weaken the security of their system, without their consent, as a result of
your actions.

You must follow the programming guidelines enforced by Microsoft on behalf
of all the users of their operating system.

--
- JB
Microsoft MVP - Windows Shell/User

Windows Vista Support Faq
http://www.jimmah.com/vista/
 
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?
Click to expand...

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." :)
 
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
 
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.
 
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
 
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 here: 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 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/windowsvista/aa904987.aspx
 
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/
 
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.
 
On Sat, 10 Feb 2007 10:46:32 -0800, "Kerry Brown"
in said:
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.
Click to expand...

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/~pgut001/pubs/vista_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.
 
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!
Click to expand...

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".
 
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.
Click to expand...

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.
Click to expand...

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? :)
Click to expand...

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.
Click to expand...

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".
Click to expand...

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.
Click to expand...

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".
Click to expand...

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/
 
mayayana said:
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".
Click to expand...


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.
 
[writing to Program Files]
You do not "work around Windows" by subverting it!
Software that does this is called 'malware'.
Click to expand...
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, ...
Click to expand...
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 :).
Click to expand...
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
 
Back
Top