Full Control to Users programmatically

  • Thread starter Thread starter vovan
  • Start date Start date
Dave O. said:
Sure I can understand MS not getting it right for minor applications and
little tools but SQL Server is a flagship product which does handle some
mission critical information for some users, there is no way that they
should have let it out of the door storing data off the ProgramFiles
folder tree. This is an indication of the poor product testing or the lack
of knowledge of the testers at MS as well as inadequate briefing of
developers at MS who should have known this was or would become a problem.

Regards
Dave O.
Click to expand...


And your point is?

Because some product groups at Microsoft used poor programming choices many
years ago all programmers today can ignore current guidelines and do what
ever they want without consequences? I fail to follow that logic. Maybe you
were thinking of something else? Possibly this - Some product groups at
Microsoft made some poor choices in the past so Microsoft is forever bound
to keep repeating those mistakes?

Yes, SQL 2000 shouldn't have defaulted to storing data in the Program Files
hierarchy. I realized this years ago and never did allow this to happen. The
choice was there. Making mistakes in the past doesn't mean you have to keep
repeating them. Thankfully Microsoft has realized this was a mistake and is
changing their ways. Why can't everyone else. Are you afraid to move on? As
with some developers some product groups at Microsoft are struggling with
this. This doesn't mean security should be abandoned just because it's hard.
Programmers should be looking at this as an opportunity to improve their
methods and as a way to help them create more portable applications. It will
take some work as do most things in life.

In some ways your use of SQL as an example is not really a good one. SQL
data files are not normally directly accessed by end users but accessed
through a data connector. The SQL service is the process that is actually
updating the data not the program the end user is running. I do agree that
Program Files is still the wrong place for the data but in some ways having
it there actually increases the security of the data files. There are many
other examples of Microsoft products that have used Program Files for data
storage in the past. SQL is probably not the best example.
 
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
Click to expand...

Ok, I have read this entire thread and I think I understand what is
being stated as the "correct" way to do things. If I understand
correctly, my app should install itself to the ...Program Files\My App
folder. Further it should store its data in the ...Documents and
Settings\{current user}\Application Data folder.
Is this correct?
If it is indeed correct where should I store a 20 to 100 meg data file
for an application which will be used by many users?
Do I store a copy of the file in each users folder?
If so how do I keep the various copies synchronized?

Just wondering,
Steve
 
On Mon, 12 Feb 2007 08:04:49 -0800, "Ken Halter"
...because MS has no other way of preventing a virus
from infecting a users files, then... guess what. That user is an idiot
anyway and deserves to have their files wasted. As anyone ever heard the
term "backup"?
Click to expand...

Yep, part of the problem is a broken data/code distinction, both by
design (autorunning macros in "documents", scripts in HTML plus
pervasive use of HTML as generic "rich text") and via exploit (GDI
Plus, WMF, etc.). It doesn't help when MS replaces a complex but
reasonably accurate file name extension with self-spoofable icons,
before going on to undermine extensions by acting on hidden type cues
embedded within the file itself.

But simple date-based backup is close to useless as a way of hedging
against malware, which is often designed to avoid being detected until
Payload Day or (as more common now) for its working life.

So you have to scope between backed-up data and malware or infectable
code, it you aren't going to restore malware with the backups.

In an age of "code of the day" patching, you can't combine a
scoped-out data backup with a day-zero code base, known to be
malware-free because it was saved before malware exposure. If you
take an unpatched code base online to patch it, you may very well get
malware'd before your patches are downloaded.

So, how do you maintain an up-to-the-minute fully-patched code base
backup that excludes malware? Are you going to use the same av that
missed the malware in the first place, to scan this code base and data
backups before use? If so, from what ?clean OS will you do this scan?


--------------- ---- --- -- - - - -
Click to expand...
Saws are too hard to use.
Be easier to use!
 
¤ > 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
¤
¤ Ok, I have read this entire thread and I think I understand what is
¤ being stated as the "correct" way to do things. If I understand
¤ correctly, my app should install itself to the ...Program Files\My App
¤ folder. Further it should store its data in the ...Documents and
¤ Settings\{current user}\Application Data folder.
¤ Is this correct?
¤ If it is indeed correct where should I store a 20 to 100 meg data file
¤ for an application which will be used by many users?
¤ Do I store a copy of the file in each users folder?
¤ If so how do I keep the various copies synchronized?
¤

Have you tried using the All Users location?


Paul
~~~~
Microsoft MVP (Visual Basic)
 
¤ > 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 thereis 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
¤
¤ Ok, I have read this entire thread and I think I understand what is
¤ being stated as the "correct" way to do things. If I understand
¤ correctly, my app should install itself to the ...Program Files\My App
¤ folder. Further it should store its data in the ...Documents and
¤ Settings\{current user}\Application Data folder.
¤ Is this correct?
¤ If it is indeed correct where should I store a 20 to 100 meg data file
¤ for an application which will be used by many users?
¤ Do I store a copy of the file in each users folder?
¤ If so how do I keep the various copies synchronized?
¤

Have you tried using the All Users location?

Paul
~~~~
Microsoft MVP (Visual Basic)
Click to expand...

I have not "tried" any of this (I always just used App.Path...does
that make me a bad person :) ). However I read this quote and
understood that such a solution was really no solution at all.
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.
Click to expand...

Am I mis understanding it or is this poster simply wrong? Or is this
simply not really a solution?

BTW The quote above is excerpted(sp) from post #23 by Schmidt

Steve
 
¤ > 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
¤
¤ Ok, I have read this entire thread and I think I understand what is
¤ being stated as the "correct" way to do things. If I understand
¤ correctly, my app should install itself to the ...Program Files\My App
¤ folder. Further it should store its data in the ...Documents and
¤ Settings\{current user}\Application Data folder.
¤ Is this correct?
¤ If it is indeed correct where should I store a 20 to 100 meg data file
¤ for an application which will be used by many users?
¤ Do I store a copy of the file in each users folder?
¤ If so how do I keep the various copies synchronized?
¤

Have you tried using the All Users location?

Paul
~~~~
Microsoft MVP (Visual Basic)
Click to expand...

I have not "tried" any of this (I always just used App.Path...does
that make me a bad person :) ). However I read this quote and
understood that such a solution was really no solution at all.
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.

Am I mis understanding it or is this poster simply wrong? Or is this
simply not really a solution?

BTW The quote above is excerpted(sp) from post #23 by Schmidt
Click to expand...


I'm guessing as I don't program any more but you could try APPDATA or
LOCALAPPDATA for user specific stuff and ALLUSERSPROFILE for data that needs
to be shared. Type SET at a cmd prompt :-)
 
I have not "tried" any of this (I always just used App.Path...does
that make me a bad person :) ). However I read this quote and
understood that such a solution was really no solution at all.








I'm guessing as I don't program any more but you could try APPDATA or
LOCALAPPDATA for user specific stuff and ALLUSERSPROFILE for data that needs
to be shared. Type SET at a cmd prompt :-)

--
Kerry Brown
Microsoft MVP - Shell/Userhttp://www.vistahelp.ca- Hide quoted text -

- Show quoted text -- Hide quoted text -

- Show quoted text -
Click to expand...

According to the post I quoted, putting data in the Allusers AppData
will not really work...Any user other than the owner of the data file
still does not have write privileges to that data file (although they
do presumably have read access).

Steve
 
I have not "tried" any of this (I always just used App.Path...does
that make me a bad person :) ). However I read this quote and
understood that such a solution was really no solution at all.








I'm guessing as I don't program any more but you could try APPDATA or
LOCALAPPDATA for user specific stuff and ALLUSERSPROFILE for data that
needs
to be shared. Type SET at a cmd prompt :-)


According to the post I quoted, putting data in the Allusers AppData
will not really work...Any user other than the owner of the data file
still does not have write privileges to that data file (although they
do presumably have read access).
Click to expand...

I am not a programmer and I have only perused the guidelines for Vista. I
just tried creating a folder in ALLUSERSPROFILE (C:\ProgramData) and was
easily able to change the ACLs to allow others to access it. Same with
PUBLIC (C:\Users\Public). I could be wrong but I see no reason not to change
ACLs for folders you create in these places. As I said don't take my word as
gospel or the correct way to do it. Read the documentation available on
MSDN, it's free. I believe you use the SHGetKnownFolderPath function. In
this case with the "ProgramData" Knownfolder_ID which used to be
CSIDL_COMMON_APPDATA. I'm guessing that returns C:\ProgramData but I haven't
tested it.

http://msdn2.microsoft.com/en-us/library/aa370810.aspx
 
Am I mis understanding it or is this poster simply wrong? Or is
this simply not really a solution?
Click to expand...

My quoted post is based on tests on (german) XP only.
There you can create Accounts based on the (predefined)
Useraccounts (over Group-Memberships) as "Benutzer"
and "HauptBenutzer" - in english probably something like
"Users" and "MainUsers".
The MainUsers have more rights than the "normal" Users
(in another post I've named them "advanced" and "reduced"
User-Accounts.

The restrictions from my quote above are related to the
"normal", "reduced" UserAccounts, not the MainUsers.
Don't know, if the "Standard-Useraccount" on Vista
is closer to XPs normal, reduced Useraccount or closer
to XPs advanced, MainUser-Account.

I'll write the last sentence from the above quote again,
because it was not entirely correct.
[Regarding Data-Files, in AllUsers-Documents]
[XP-only -> Vista not yet checked]
"This means, either FamilyAddresses.exe has to run
under an Admin- or a MainUser-Account ...
or an Admin or the Creator of the Data-File allows
write access on this file for other "reduced Users"
explicitely (either by hand or using the appropriate APIs)."

Olaf
 
According to the post I quoted, putting data in the Allusers AppData
will not really work...Any user other than the owner of the data file
still does not have write privileges to that data file (although they
do presumably have read access).

Steve

I'd have to test that to be sure, I haven't tried it, but the owner could
modify permissions..
 
¤ > Have you tried using the All Users location?
¤ >
¤ > Paul
¤ > ~~~~
¤ > Microsoft MVP (Visual Basic)
¤
¤ I have not "tried" any of this (I always just used App.Path...does
¤ that make me a bad person :) ). However I read this quote and
¤ understood that such a solution was really no solution at all.
¤
¤ >> 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.
¤
¤ Am I mis understanding it or is this poster simply wrong? Or is this
¤ simply not really a solution?
¤
¤ BTW The quote above is excerpted(sp) from post #23 by Schmidt

I think there's more to it than that. In the example above, where an Access database is used, all
users must have full control over the folder where the file is located. I don't know if you're
working with an Access database, but there is simply no way around this because the Jet database
engine needs to be able to manage the corresponding .LDB file.

You have to keep in mind that each scenario can be different, and what someone describes in one
scenario may not necessarily apply to yours. We can spend all month discussing the implementation,
but a proof (or failed proof) of concept is much easier to address.


Paul
~~~~
Microsoft MVP (Visual Basic)
 
mayayana said:
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." :)
Click to expand...
Or you could say this:
I'm to lazy to code this correctly so I am trying to hack it and in the
process I will destroy your windows security. Sorry.
 
I have a question that may relate to the current discussion....

I am currently using my husbands computer because mine is on its' last legs.
I have created a new user account for myself, but am unable to print any
documents. It seems my only choice is to save each document as a "XPS" file
on the hard drive, but I am still not able to print them.

I can print when I am on my husband's desk top I imagine because he is the
administrator. I know there is a relatively simple solution for this, but
being technically challenged, I, so far, haven't been able to figure it out!

Any help would be much appreciated!
 
It could be he has the printer installed for this user onl, in that case you
have to reinstall the printer for use with your account.

Else it would have worked!

Ko.
 
I am currently using my husbands computer because mine is on
its' last legs. I have created a new user account for myself, but
am unable to print any documents.
Click to expand...

Just get your husband (or yourself) to reinstall the printer for all users.
You may have to uninstall it first.

Mike
 
Back
Top