Admin privileges, UAC disabled, anti-virus program running etc

[mgh 89]

Why do some FS developers seem to be unable to cope with these?

[JB3DG 225]

Depends on what sort of extra files their gauges and modules in the sim needs to create and such....And security systems sometimes get nailed as false positives by the AV programs out there.

[pete_auau 1,158]

Maybe  you should  ask them  would be the best way to go

[mgh 89]

It's the developers'  problem - not mine.

[Don t moderate me this way 882]

Not sure I understand the question:

 

A flightsim (addon) software is supposed to circumvent computer security like UAC ... but, at the same time, AV software should not flag that as suspicious program behaviour?

 

Isn't that exactly what malware tries to achieve? Bypass PC security and hide from detection by AV software?

[Jim Young 2,356]

There are some, like PMDG, that provide instructions on installing their products albeit not before installing but after the fact (see page 22 of their PMDG 777 Introduction document).  A product will usually still work if you fail to disable UAC or an anti-virus program.  Until recently I installed everything in the default folders and had no issues whatsoever but I did have UAC disabled and I do not use an anti-virus program.  On my last reinstall in February, I decided to install FSX/P3D in K:\FSX and K:\P3D.   I ran into some problems but took ownership of the FSX and P3D directories and that seemed to fix things.  Isn't this a problem with any software installation and not just FSX/P3D/X-Plane?  Microsoft Visuals are used to make sure an application is installed properly as intended by the developer.  Maybe Microsoft should add this to their programs.

 

Best regards,

[mgh 89]

I ask because in the last year,  I have installed the following major applications:

 

Adobe Photoshop

Adobe Light Room

Borland C++Builder

Microsoft Visual Studio Community 2013

Mozilla Firefox

Mozilla Thunderbird

 

 plus a nunber of smaller ones.

 

None of these have  problems with admin privileges, UAC disabled, anti-virus program running etc. They all "click and install".

[SteveW 1,792]

It's the developers'  problem - not mine.

Gerry's correct. Some software programs and addons install files into read only areas when they must be able to write to them when running with User privileges. Some, very few, write to Admin only areas of the Registry, so User privileges won't allow it and the app fails.

 

Generally, most programs are written to comply with permissions correctly. However many that grew up with Windows XP were not tested properly with User privileges because the standard account had Admin privileges.

 

In fact installing files into the FSX/P3D Program Files folder, that will subsequently expect Write privileges to those files, will fail when the user does not have admin access. Unless the installer routine (or manual setting), set the correct privileges during setup (or at some stage previously).

 

Since anyone logging into a Windows system becomes a member of the Users Group, the most simple solution to those problems, is to add Write and Modify permissions to the Users Group, on the FSX/P3D installation folder - wherever that folder is.

 

Apps that set system settings may ask the user for elevated privileges before continuing. However some just expect to be Run as Admin, leaving it up to the user to work it out.

[SteveW 1,792]

FSX-SE has gone some way to prevent problems in this area, they have enabled Write and Modify permissions for the Users Group on the SteamApps folders.

 

However, FSX-SE introduces a new problem; emanating from the ProgramData folder...

 

Windows Vista and above:

"C:\ProgramData\Microsoft\FSX"

"C:\ProgramData\Microsoft\FSX-SE"

 

(Windows XP: "C:\Documents and Settings\All Users\Application Data")

 

 

FSX Users get access via the Authenticated Users Group, but for FSX-SE Users Group, there are no Write permissions. The FSX-SE executable is set deliberately to invoke elevation to Admin privileges to avoid problems associated with this, during first running the sim, and after installing or updating. The Admin invoking UAC can be removed from fsx.exe with a hexeditor, and the Users Group can be given Write and Modify permissions on the ProgramData folder, if you feel like showing your PC who's boss

[n4gix 4,947]

In fact installing files into the FSX/P3D Program Files folder, that will subsequently expect Write privileges to those files, will fail when the user does not have admin access. Unless the installer routine (or manual setting), set the correct privileges during setup (or at some stage previously).

It is critically important to keep in mind that FSX was first developed and released long before UAC became common enough to become a problem. However, even then there was a constant flood of complaints along the lines of "My edits of an aircraft.cfg file can't be saved!"

 

Which is precisely how and why the advice to install FSX anywhere except the default path came about. By moving the entire program outside of the heavily protected areas of the operating system's structure, nearly all of these kind of issues may be avoided.

 

Both DTG and L-M have been taking steps to ameliorate these problems by moving as much as possible of the "configurable stuff" into less well protected folder paths. FSX (disk edition) of course is frozen in time, and cannot be 'fixed' at this late date!

 

New program versions - such as those cited by Gerry - that have been released over the past few years have been deliberately designed to take all of these issues into account, so few - if any - problems will ever occur. It's blatantly unfair to compare such new program versions with FSX (disk edition).

 

Given how many developers rely on such crude solutions such as "ClickTeam" or their own home-brewed installers to handle their installations, I'm not the least bit comfortable with the idea of entrusting "them" to make radical and potentially dangerous modifications to my computer's security...

[SteveW 1,792]

It is critically important to keep in mind that FSX was first developed and released long before UAC became common enough to become a problem.

Although FSX was developed many years ago, it's designed correctly for Windows. It was precisely the mis-use of folders and Registry by other programs that brought on the UAC dialog and the requirement to set permissions.

 

 

Which is precisely how and why the advice to install FSX anywhere except the default path came about. By moving the entire program outside of the heavily protected areas of the operating system's structure, nearly all of these kind of issues may be avoided.

Only the permissions need be set on the default installation location. Making the installation in another folder is simply one way round the problem, but it's not recommended since some installs get alternative locations incorrect, and still requires the proper permissions set for the Users Group to avoid all issues relating to security.

 

Setting UAC off and running as Admin is the way to get infected. Removing the requirement of running as Admin is the proper way to go.

 

...It seems many still cling to mis-placed ideas relating to Windows security; making the account an Admin, setting UAC off, taking ownership; these are all mistakes. Only the correct permissions need be set once for the folders requiring secure access (those apps accessing the Admin part of the Registry still require running as admin). These proper permissions maintain security, these old methods break it.

[scott967 62]

IIUC Windows security is structured to encourage developers to release signed code that has been verified by one of MS' preferred CA providers.  Of course this adds complexity and expense so developers might not see the "value added" and instead promote disabling UAC.

 

From a user perspective, I admit I don't do it but have wondered if it would be better to use an admin group account to do actual admin functions, and actually run FSX with a different user account that is kept clean.

 

scott s.

.

[SteveW 1,792]

to release signed code that has been verified by one of MS' preferred CA providers.

This has come up since Windows was thought up, but many organisations have much business binding software, aka 'scratchware', that it would impose too much restriction to anyone developing code to run with their business data. It's expensive to do and so high profile apps can include certification and afford it, and they look good and proper too.

 

However, a good installer when run should be run in user mode, check itself for malware and exit if suspicious, or elevate to admin mode with the OK dialog to continue with the system changes. Many don't do this. If a program has malware attached and is Run as Admin, that malware is already installed before the setup program gets underway properly.

[SteveW 1,792]

 

What often comes up is that a user installs FSX and then installs an addon that wants to make changes to the stock aircraft files. What the app should do is create a new folder for changed aircraft, and add to the list of aircraft locations. The original aircraft should be aliased and the changes made to the config and panel files of the edited aircraft, so that edited aircraft appear alongside the originals. Instead the user is expected to understand the problem of the app not having permissions. All along the easy way round this was to simply add Write and Modify permissions to the Users Group for the installed folder.

[goates 576]

New program versions - such as those cited by Gerry - that have been released over the past few years have been deliberately designed to take all of these issues into account, so few - if any - problems will ever occur. It's blatantly unfair to compare such new program versions with FSX (disk edition).

 

It has little to do with new vs. old releases. Many applications handled UAC just fine, and before that, ran under limited user accounts without trouble as they had been developed to work in the corporate world where few, if any, users ran with full admin permissions. The problems with UAC were mostly from the consumer side as most home users were running as admins under XP, and before that under Win95-ME user permissions didn't really exist. On the other hand Windows XP's predecessors, Windows NT and 2000, had supported restricted accounts for many years. Microsoft had been trying, somewhat half heartedly, to get developers to update their applications when XP came out, but few seemed to really listen or care.

 

Some comments that supposedly came out of Microsoft when Vista was released claimed that UAC was deliberately designed to be annoying so as to put pressure on developers who hadn't properly updated their programs. If so, I think it backfired as it has now become "common knowledge" that UAC is just a nuisance to be disabled.

 

 

Setting UAC off and running as Admin is the way to get infected. Removing the requirement of running as Admin is the proper way to go.

 

...It seems many still cling to mis-placed ideas relating to Windows security; making the account an Admin, setting UAC off, taking ownership; these are all mistakes. Only the correct permissions need be set once for the folders requiring secure access (those apps accessing the Admin part of the Registry still require running as admin). These proper permissions maintain security, these old methods break it.

 

Yep, far too many take UAC to mean Microsoft is trying to take away control of the computer from the computer's owner. In reality, the point is to make sure the computer stays under the control of the computer's owner, not some malicious virus or malware author on the internet somewhere.