Announcement

Collapse
No announcement yet.

Program Files Folder

Collapse
X
 
  • Filter
  • Time
  • Show
Clear All
new posts

  • Program Files Folder

    All of the apps I've published have been provided as a Zip file, just unzip and off you go.

    So I was experimenting today with placing an app in "c:\Program Files (x86)"

    I manually created a new "c:\program files (x86) subfolder called "New Folder". It took Admin rights to do that.

    I noticed that right-clicking in the New Folder showed the "New" context menu as expect, but when I used it, the submenu only contains the option to create a new folder, NOT a new file.

    So, I then created a file newfolder.bas elsewhere and moved it into the "New Folder". When I tried to compile it, I get a compile error "Destination File Write Error"

    I ran PBWin using the right mouse "Run As Administrator" option and then it would load and compile just fine.

    I saw similar problems with the created EXE. To make it run, I couldn't simply double click on it, I had to Run as Administrator and the user had to answer Y/N to run the app.

    Seems like I've always read about issues with working in "Program Files" but I've just not paid close attention.

    Is there a summary around here of the issues with using Program Files and how to work around them with installed PowerBASIC apps? I've found misc comments, but nothing comprehensive.



  • #2
    As a security professional I'd HIGHLY SUGGEST NOT "working-around" permissions and/or the UAC (in that we should not change Windows just to make our apps work) and we should work within the framework so we change our apps to work with the Windows security features unchanged.

    https://docs.microsoft.com/en-us/win...-control-works is a good start to understand UAC.

    Also, If you are going to have your app live in the "program files(x)" area you should switch to using standardized installers (Windows MSI, Nullsoft, Wise, Inno Setup, etc.) to handle it all. This way it allows a simple uninstall as well using known/expected interfaces.

    Also, the issues most programmers encounter are caused by them still thinking that best practices is to store all data in the same directory as the EXE (or at least in the same localized folder structure to the EXE). Only PURELY static or VERY RARELY updated (think version changes) data should reside there; dynamic data of any sort should reside in appropriate data directories or the registry. Typically "settings" get stored in the registry and are split between HKLM and HKCU depending on if the settings are per user or global for all users on a machine. Databases and other sorts of data belong in the appropriate data folder depending on if the data should be per machine, per user, or even should follow the user as they roam in a multi-computer environment. It's not an easy answer in a forum post and will require thoughtful analysis of the data and app purpose to determine what is the best suited storage location (also see https://docs.microsoft.com/en-us/win.../knownfolderid)
    <b>George W. Bleck</b>
    <img src='http://www.blecktech.com/myemail.gif'>

    Comment


    • #3
      A setup program runs as Administrator so it inherits rights to copy files to the location. You could do the same to copy the files there and as long as your app does not try and create files in the app folder, you will achieve the same result as the install programs but your app will not be in the Add/Remove programs. Personally I use inni setup and it is quick and easy to create a distribution file.

      Comment


      • #4
        Hey George,
        Thanks for the response!

        Sorry, but "work around" was a bad choice of words. I really meant "work within" the constraints that Windows puts in place.

        I'm using Inno Setup in my testing.

        I'll look at the links and I'm sure I'll have more questions.

        Comment


        • #5
          Carlo,
          Sorry, missed your post while I was responding to George.

          This is exactly the type of constraint I need to understand.

          ...as your app does not try and create files in the app folder
          I'll definitely follow up on the links from George.

          Comment


          • #6
            UAC sucks the balls off a dead dog. It should be disabled for anything short of running a neuclear power station.

            Comment


            • #7
              Howdy, James!
              However much you made me chuckle, I have to deal with what my customer PC's have to offer.

              Comment


              • #8
                Originally posted by James McNab View Post
                UAC sucks the balls off a dead dog. It should be disabled for anything short of running a neuclear power station.
                *SlowClap*

                And exactly this attitude causes all the havoc malware creates these days. And for a programmer, this is outright irrespobsible. I do hope your clients are aware of your attitude towards security...

                Comment


                • #9
                  James McNab I can understand your frustration but it is IMPERATIVE you accept this change and acknowledge it is there for VERY good reasons. This isn't something Microsoft did just to piss off customers. On the contrary, Microsoft took a LOT of flack for years not having it. Sadly, when they did it implement it Apple killed them in their advertisements further confusing clients, but it was completely unwarranted and did everyone a disservice. It's there to fight the enormous amount of malware trying to attack your machine. This is just one layer of the many layers of security you need and should have to protect your device.

                  There are organized crime syndicates as well as many nation states that would VERY willingly love to take over your machine, either to steal your credentials, steal money from your accounts, or use your PC as part of a bot-net or jump point to attack or infect other devices on the internet. This is not tin-foil hat stuff, this is VERY REAL, happening every day, and infects PC's without it running the most because they leave the door wide open. You don't have to believe me, but you really should. There are a myriad of sites explaining why you should have it... here is just one https://malwaretips.com/threads/why-...tect-you.47157.
                  <b>George W. Bleck</b>
                  <img src='http://www.blecktech.com/myemail.gif'>

                  Comment


                  • #10
                    I guess it comes down to perspective, I am a tinkerer so have no commercial pressure to implement whatever measures some security expert has suggested. A few simple rules, don't run untrusted executables, don't run Java, don't open untrusted emails and don't store passwords either locally or with some remote application. These, along with offline OS images and regular offline data backups, have keeped me safe.

                    In fairness, I should add that the consequences of a malware attack for me are minimal but somewhat more so if you have clients relying on you recommendation. Or more simply put, horses for courses.

                    Oh, and by the way, I wouldn't run a nuclear power station with a microsoft product, with or without UAC, scanning AV etc etc

                    Comment


                    • #11
                      This thread is starting to get side-tracked but what you are implementing is simply not enough, despite what you may think.

                      Just simply surfing the internet you can hit a compromised website which in turn can take advantage of a either a "zero day" or unpatched vulnerability (regardless of java version or install status) on your PC and you are toast. "Being careful" is just not enough, you need actual tools to stop the escalation of rights.

                      And "storing passwords" is not the issue. Keyloggers are so much easier to implement.
                      <b>George W. Bleck</b>
                      <img src='http://www.blecktech.com/myemail.gif'>

                      Comment


                      • #12
                        Yes, my intent wasn't a discussion on the merits of security measures, but rather what steps my PowerBASIC app must follow to be an arguably safe guest on my user's PC.

                        Comment


                        • #13
                          George

                          Perhaps you can help clarify something for me.

                          The UAC is to prevent apps from performing a set of monitored/restricted tasks, system actions for the most part. Call those rogue apps, or at least apps that need permission to take those actions.

                          So, if an app doesn't do that, call it a good app, is there a security risk to the user?

                          I look at the UAC as a mean of corralling a rogue app. I don't have the big picture, I guess, of the risk associated with a good app being placed in a random location.

                          Consider these two events:

                          1. A user takes one of my apps and unzips it into a folder of his choice, not "Program Files (x86)"
                          2. My apps comes as an EXE that installs itself in the same folder

                          None of my apps attempt to perform the "things which cannot be done without administrator rights:", as was discussed in one of the links you gave me.

                          Does either of these describe an event which is actually dangerous to the user? Or just one that violates the security guidelines?

                          I understand the idea that UAC helps protect the user against bad choices/hidden villains - the uncertainty of what is a rogue app and a good app. But I suspect there's more to it than my simple example. Perhaps you can expand on the topic?

                          Comment


                          • #14
                            UAC protected folders

                            CommonProgramData

                            Comment


                            • #15
                              Originally posted by George Bleck View Post
                              This thread is starting to get side-tracked but what you are implementing is simply not enough, despite what you may think.

                              Just simply surfing the internet you can hit a compromised website which in turn can take advantage of a either a "zero day" or unpatched vulnerability (regardless of java version or install status) on your PC and you are toast. "Being careful" is just not enough, you need actual tools to stop the escalation of rights.

                              And "storing passwords" is not the issue. Keyloggers are so much easier to implement.
                              By all means have the last word but for my part I'm happy to agree to disagree.

                              Comment


                              • #16
                                As long as your app does not try to do anything that requires rights elevation (i.e. access a restricted location or perform a restricted action) then UAC would (should?) not impact/impede your app in any way.

                                The moment you try to do something like that UAC will step in. There are multiple action that can happen from there. Depending how your app was developed, and on your manifest configuration, and how windows perceives you app (legacy, etc.) it may stop APIs or File Access commands from working (and return an error that you need to react to) or it my prompt your for rights elevation,

                                OR

                                It might virtualize your access to whatever resources you were trying to access such that it still protects the main location but also allows the app to function. Here is a good read http://techgenix.com/protecting-syst...ization-part1/
                                <b>George W. Bleck</b>
                                <img src='http://www.blecktech.com/myemail.gif'>

                                Comment


                                • #17
                                  The long and short of it is, if you're redistributing software to third parties, create an installer for your applications (self-installing executables, installer packages, whatever you prefer) and digitally sign them with an Authenticode certificate. This does a few things. First, not only does it simplify things for your users in terms of installation, it also makes it easier for them to remove it. A "real" installer will also include your software in the list of installed programs so they can easily see what has been (or has not been) installed, the version, etc.

                                  Digitally signing the installer (and optionally your executables themselves) gives them assurance that it has not been tampered with. It also prevents Windows from displaying warnings to the end user about the installer coming from an unknown and potentially untrusted source.
                                  Mike Stefanik
                                  sockettools.com

                                  Comment


                                  • #18
                                    Originally posted by James McNab View Post
                                    I guess it comes down to perspective, I am a tinkerer so have no commercial pressure to implement whatever measures some security expert has suggested. A few simple rules, don't run untrusted executables, don't run Java, don't open untrusted emails and don't store passwords either locally or with some remote application. These, along with offline OS images and regular offline data backups, have keeped me safe.
                                    This has less to do with perspective, but reducing potential harm. Not just for yourself, but for everyone. You think you might be safe, but i you're wrong and your machine gets infected, it may be used to spread out malicious things to other machines. So your'e negligence potentially hurts not only you, but others as well.

                                    And the bolded there makes me think that you are one of those guys who benefits from UAC ...

                                    Comment

                                    Working...
                                    X