Full Control to Users programmatically

Discussion in 'Windows Vista Administration' started by vovan, Feb 10, 2007.

  1. vovan

    vovan Guest

    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
     
    vovan, Feb 10, 2007
    #1
    1. Advertisements

  2. vovan

    Jack Guest

    I guess you need to change the design.
    Do not use c:\program files folder.
     
    Jack, Feb 10, 2007
    #2
    1. Advertisements

  3. vovan

    vovan Guest

    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
     
    vovan, Feb 10, 2007
    #3
  4. vovan

    Jimmy Brush Guest

    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/
     
    Jimmy Brush, Feb 10, 2007
    #4
  5. vovan

    vovan Guest

    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
     
    vovan, Feb 10, 2007
    #5
  6. vovan

    Jimmy Brush Guest

    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/
     
    Jimmy Brush, Feb 10, 2007
    #6
  7. vovan

    mayayana Guest

    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." :)
     
    mayayana, Feb 10, 2007
    #7
  8. vovan

    vovan Guest

    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
     
    vovan, Feb 10, 2007
    #8
  9. vovan

    Kerry Brown Guest

    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, Feb 10, 2007
    #9
  10. vovan

    vovan Guest

    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
     
    vovan, Feb 10, 2007
    #10
  11. vovan

    mayayana Guest

    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.
     
    mayayana, Feb 10, 2007
    #11
  12. vovan

    Kerry Brown Guest

    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
     
    Kerry Brown, Feb 10, 2007
    #12
  13. vovan

    Jimmy Brush Guest

    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/
     
    Jimmy Brush, Feb 10, 2007
    #13
  14. 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.
     
    David J. Craig, Feb 11, 2007
    #14
  15. On Sat, 10 Feb 2007 10:46:32 -0800, "Kerry Brown"
    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.
     
    Stefan Berglund, Feb 11, 2007
    #15
  16. vovan

    mayayana Guest

    Look guys,
    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".
     
    mayayana, Feb 11, 2007
    #16
  17. vovan

    Jimmy Brush Guest

    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'.
    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.
    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 :)
    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.
    Of course it is. Your application must interface with Windows the way
    Microsoft requires it to.
    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.
    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/
     
    Jimmy Brush, Feb 11, 2007
    #17
  18. vovan

    Kerry Brown Guest

    What does DRM have to do with any of the discussion in this thread?
     
    Kerry Brown, Feb 11, 2007
    #18
  19. vovan

    Kerry Brown Guest


    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, Feb 11, 2007
    #19
  20. vovan

    Schmidt Guest

    [writing to Program Files]
    So MS-Office (prior 2007), MS VisualStudio (.NET too), etc.
    is malware - good to know.
    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.
    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
     
    Schmidt, Feb 11, 2007
    #20
    1. Advertisements

Ask a Question

Want to reply to this thread or ask your own question?

You'll need to choose a username for the site, which only take a couple of moments (here). After that, you can post your question and our members will help you out.