Export thread

Hi gang,

I lurk and sometimes post in the GRC newsgroups, but when something related to coding practices came up I couldn't think of a better place to start looking for answers than the folks here. Paul H and Barry W suggested I post here. Hi guys!

Some of my extended family through marriage own, operate, and perform at a live music venue. The question I have is about their ticketing system.

The system, used to handle all aspects of reserving seats, buying, and printing tickets for both individuals and groups, is old. It was originally born at least 25 years ago iiuc, but the guy who wrote it still maintains it, tinkers with it, and adds new custom features upon request. Although it looks and feels like an older app, still runs just fine on modern Windows machines, with one very big caveat: it requires administrator permissions to launch.

The developer is one of those guys that seems to find fault with everything Microsoft does, particularly with the inconveniences related to tightening up security. He'd rather complain than try to understand the reasons behind their decisions. While I agree that Microsoft still gives us plenty of reasons to fault them, taking actions to make their OS and their users safer and more secure is clearly the right call. Not needing to be an admin to run normal programs has been the accepted conventional wisdom for quite some time now.

Over the years whenever I've had occasion to work with him on something, I've consistently urged him to update his system so that users don't need to be administrators to run it. The problem is, I'm not a developer. And in talking to him, it's recently become clear that he himself has no idea why his application asks for administrator permissions.

The application is written in Visual Fox Pro, which most here probably know has been unsupported for years now. Since I'm not a coder, I have NO idea what advice to give him or what resources I could direct him to to help him figure out how to update his system so that it no longer requires admin rights. What feature or process or method within his application is responsible for triggering the request for administrator permissions? He has no idea, and I have no real idea how to help him.

The system architecture is pretty simple. He has no installer. To set up a new workstation, there's a collection of files that you copy to a folder in the root of the C: drive; C:\Tickets is the path. Then you give users a shortcut to a particular executable within that folder. There's a shared folder on a local server with a bunch more files which the client-side files communicate, which presumably includes a Visual Fox Pro database of some kind.

I've had a number of ideas on things to try, but his system makes many assumptions about the locations of files, so all of them require him to make multiple changes to his system in order to test:

• What if the application is run from within Program Files (x86)? I think that's probably important. Would Admin rights still be requested?
• What if he packages the application into an installer, so we're not just copying files to a folder to deploy? Does that have any bearing?
• Is he using methods or processes that have been deprecated instead of newer APIs or Windows features that have been rearchitected specifically to remove the Admin requirement? If so, how does he identify them and update them?
• Are there tools designed specifically to help developers solve this problem?
• Even if there are such tools, is VFP simply too old to be capable of operating without admin rights in a modern Windows environment?

If I were to suggest things he could try, it would be a clear case of the blind leading the blind. Rather than shoot in the dark trying random things, I think it's better to find tools and/or documentation that can clearly help identify and lay out what must be done to bring a VFP application into the modern Windows world. Since he doesn't seem particularly motivated to make even this change, I'm SURE there's no way in hell he would take on the task of doing a complete rewrite of his system in a new and unfamiliar language. He simply doesn't have the resources. But he did agree that if I could find him help and resources on how to solve this admin rights problem, he'd be willing to look at it.

I know that was a long post, so thanks for reading. All thoughts welcome!

- Bryan

Running procmon from SysInternals should show you what files/registry keys etc are being accessed and whether any fail.


Download that, start it, then try running Tickets as a normal user. Look at the log for what failed.

AlanD said:

Running procmon from SysInternals should show you what files/registry keys etc are being accessed and whether any fail.

Process Monitor - Sysinternals

Monitor file system, Registry, process, thread and DLL activity in real-time.

learn.microsoft.com

Download that, start it, then try running Tickets as a normal user. Look at the log for what failed.

Click to expand...

Thanks Alan. Would that be useful if the app *immediately* asks for admin rights before it actually does anything? That’s what seems to happen.

I did a bit more online searching after posting, and it seems the program itself - like most programs I presume? - contains a manifest of what it needs, and that triggers it? Or do not all programming languages result in .EXEs that contain a manifest?

DragonRand said:

asks for admin rights before it actually does anything? That’s what seems to happen.

Click to expand...

That is likely a setting in the properties for the icon that launches the app. You would normally set this when installing it so it asks for elevation at launch, to save it failing in the middle later if it needs the permissions.

If I had to guess what the likely problem would be, I would guess some file access permission. For example, maybe the app is installed in C:\Program Files (or the x86 version of the same) and wants to read/write a configuration file or database file that is in the same location. Normal users do not have permissions to write there, so elevation would be required.

DragonRand said:

Thanks Alan. Would that be useful if the app *immediately* asks for admin rights before it actually does anything? That’s what seems to happen.

Click to expand...

If you start Procmon and leave it running, before you start Tickets, it should show every resource that is requested as it happens. The Procmon display will be thousands of lines, but you can filter it to specific executables, e.g. tickets.exe. I suspect that it will only be asking for Admin rights when it tries to read something and is told "you need admin permission".

PHolder said:

That is likely a setting in the properties for the icon that launches the app. You would normally set this when installing it so it asks for elevation at launch, to save it failing in the middle later if it needs the permissions.

If I had to guess what the likely problem would be, I would guess some file access permission. For example, maybe the app is installed in C:\Program Files (or the x86 version of the same) and wants to read/write a configuration file or database file that is in the same location. Normal users do not have permissions to write there, so elevation would be required.

Click to expand...

Thanks Paul. Actually the client-side files live in C:\Tickets (see my OP). So in this case it wouldn't be due to needing to write to files within special protected file system locations like Program Files because everything it does client-side is wholly contained within that C:\Tickets folder.

Here's the .exe properties:



So it doesn't appear to be the properties manually set on the .exe. It's the application itself that immediately asks.

And I'll also note that it's at least 2-3 seconds after launching before the process seeks to find and connect to the server-side component. I know this because I've seen that process fail before. So it shouldn't be something server-side causing this. This UAC prompt is, as I said, immediate upon launching.

Bryan

DragonRand said:

connect to the server-side component

Click to expand...

Aha, that's a possible clue. In Unix networking (being the first, most OSes tend to model after it, including Windows) you're NOT allowed to "impersonate" ports below 1024. (Technically the first 1K of ports are restricted for "official" services provided by the OS, such as FTP, SMTP (email), WWW and others. If the app is wanting to use these lower ports for some reason, then it would need the permission to do so.

Well I have never in my life used Fox Pro, but it seems to me it SHOULD be very similar to DBase III which I used in university so many decades ago. In this case, it's kinda like Java. You have an executable environment that is focused on database work, but is basically a virtual machine, and it runs the code you right (interprets it most likely, although it could be compiled down to pseudo-machine code to make the interpreter run faster.) So it is either something the "VM runner" is doing to request the permissions, or some command it is interpreting that is causing that to happen. It might be the case that it won't be possible to adapt the code easily... Fox Pro may just be coded to work this way.

One thing to check, would be if you fail to authorize the elevation, does the app struggle onward, and if so is it obvious what fails later? (If anything.)

I'm just going to randomly throw this at you, in the case that something like this is the way out of your nightmare

Hi @DragonRand . I say the following as a person who was a developer in Clipper (similar to Foxpro or dBase) back in 1990, 30 plus years ago, on a DOS and Netware OS, before Windows. But, I've also been a Windows user ever since it came into existence up through Windows 7, as have many here. I consider myself a prosumer, but don't have specific expertise about the scenario you mention. But, my general knowledge might be useful. So, here are some random thoughts which might or might not be good ones. Each has pros and cons. I have quickly read this thread but may not have gotten every nuance.

* The dev could potentially ask questions here.

* You could give every user the password to elevate the privileges, and instructions when NOT to. Assuming the Tickets app is not malicious, it's not likely to become malicious unless the PC gets a virus. Still, if that happened, that could cause problems. You could also have a supervisor pre authorize and sign in certain workstations before the staff begins work.

* You could try setting UAC on one of the PC's to different levels and see what happens. On Windows 7, there are a couple of different settings. I don't know about Windows 10 or 11. I would never leave UAC set lower than it's default. I have mine set to max all the time, and am happy to enter my password when needed. If the PC is doing something "admin" like, I want to know it. That may or may not be practical for your user.

* If the users are logging into a Windows network, you could play around with the authentication and network privileges settings. I've only ever used Windows as an individual, so I cannot cite the steps. But, you could make a "Tickets Users" group and give that group admin access over only the Tickets app. Then you put appropriate users in the group. Then, the user could log in as normal and they would automatically have the authority to run Tickets ... I think. There could still be problems in the event of a virus.

* You could store all the currently local files on the server, maybe. This would slow the app down to a point. It would also potentially eliminate any UAC conflicts with the local drive or local system. I had this setup with Clipper back in the day. If you can make the program files read only on the server, it's harder for a virus to attack them. It might still be able to destroy the database, which would be bad. But, as people here have said, any time you have a bad actor inside your machine, you've got trouble. NOTE, IF you have people running the system remotely through a bridge or vpn or something, and they have to load the app from the remote server every time they run it, this can bring the system to a crawl. I had this problem back in the day with a remote site and I had to go out there and put local copies of the app on their local drive. I then had to force the remote PC to pull the app from the local drive rather than the LAN. It's not as much of a problem with high speed internet. (We had 128 Kbps of bandwidth through the bridge. No that's not a typo.) Still, if the user has to download 20 MB - 50 MB or something every time they start the app, it can be annoying. Running the app completely from the LAN will preclude running it stand alone if the LAN or server is down. But, I think you said you have some stuff on the server anyway.

* You can go into the properties of the Windows icon to start Tickets, and the properties of the exe file itself, and under the compatibility tab (at least on Windows 7), you can turn off the setting to run as administrator, if it's on. You may have to do this both on the icon and on the exe. You may have to update it every time the program exe is updated. You can see if the program will run without requiring elevated privileges. It may not. Conversely, if this setting is initially off, you can set it on to require the UAC password as soon as the program is started.

* Under the properties of the icon and the exe, under the security tab, there are a whole host of settings which control which groups and users can run the app and what privileges they have. Some of these might be useful. Knowing what to do with them is beyond my knowledge level and beyond the scope of this post.

* You may be able to poke around in the Event Viewer in Windows (in Windows 7, Start, Administrative Tools, Event viewer) to find out what's happening under the covers when the UAC request is issued. It might be useful to see what fails if the user does not enter the password and just cancels out of UAC. Does the program abort? Does it partly work? If the program throws up an error, that might contain useful data.

* The dev may be able to turn on trace mode or debugging mode in the program, to see what subroutines are triggering the UAC request and generate log files. This should never be left on in production for long as it can provide exploitable information to attackers. It can also make log files grow too huge.

That's all I can think of at the moment.

I hope this is useful and that it at least gives you some things to think about.

May your bits be stable and your interfaces be fast. Ron

PS just for kicks I decided to do a little googling. Didn't have lots of time. Use for what it's worth. I don't know anything about FoxPro and I don't know if any of this is good advice.


Visual foxpro works only when user is an administrator - Microsoft: FoxPro - Tek-Tips
https://www.tek-tips.com/viewthread.cfm?qid=994893

How to run any Visual FoxPro program as a Windows Service (8/2012/7/2008/Vista/2003/XP)

'Execute as Administrator' inconvenience - Microsoft: FoxPro - Tek-Tips

May your bits be stable and your interfaces be fast. Ron