Labview installer creates bad permissions

[sth]

On Mac OS X, I just installed LV 8.20, VISA 4.0.1 and NI-DAQmx Base 2.1.

After this process one of the installers changed the owner, group and permissions of /Library/Frameworks. This creates a potential security problem. Repair permissions will fix this, but it is wrong for the installer to do this. The permissions were correct just before I did the installation. I am not sure which of the installers did this, but I will post later as I figure this out.


User differs on ./Library/Frameworks, should be 0, owner is 501
Group differs on ./Library/Frameworks, should be 80, group is 501
Permissions differ on ./Library/Frameworks, should be drwxrwxr-x , they are drwxr-xr-x
Owner and group corrected on ./Library/Frameworks
Permissions corrected on ./Library/Frameworks

[TheDillo]

Please let us know what you find, I'm actually also looking into this on our end.

[sth]

Sure. Thanks for looking into this!

I just listed /Library/Frameworks, Reinstalled LabVIEW 8.20 and then listed the directory again.

% l -d /Library/Frameworks/
11744 0 drwxrwxr-x 46 root admin 1564 Nov 7 18:09 /Library/Frameworks//

% l -d /Library/Frameworks/
11744 0 drwxr-xr-x 46 ops ops 1564 Mar 3 2006 /Library/Frameworks//

As you can see the new owner and group area different. This was NOT the group/owner I was logged in as either!!!

This is owner/group 501 which is the first account to be created on a system. Thus the NI installer is setting the owner and group to 501. Which is bad.

Those of us who are paranoid actually run permission repair after software installs!

-Scott

[TheDillo]

I've filed a Corrective Action Request on this, it is important to note, as you've said above, that this can be fixed simply running Fix Permissions after installing.

Thanks,

[sth]

Thanks! Doing a repair permissions is a step that should not be necessary and is something that not everyone does. As a Mac user we are so far immune to malware. Consistently requiring developers to keep that gold standard is the best defence.

Can you tell me the CAR # so that I can track this and know when it is fixed or not? Thanks again.

Scott

[TheDillo]

No problem, this was filed as CAR ID: 43CF991J

[Roy_F]

The CAR # is actually 43CFE91J.

For search purposes, I'll add our standard text: This was reported to R&D (CAR # 43CFE91J) for further investigation.

Roy

[sth]

---

@Roy F wrote:

The CAR # is actually 43CFE91J.

For search purposes, I'll add our standard text: This was reported to R&D (CAR # 43CFE91J) for further investigation.

---

Wow, I just installed 8.5 and it does essentially the same thing. It is really nasty changing the /Library permissions. But also having the LabVIEW directory wide open is not good either!

There is write permission to everything!!! This is great for mass compiles, but a wide open attack vector for anyone trying to install a trojan horse. Having your entire system compromised by this install is sort of annoying. There are some simple find commands that can fix most of this. The problem is sorting out the actual executables vs the VIs that should not have executable privelege.

Do a Mass Compile from an admin account. Then do
cd /Applications/National\ Instruments/LabVIEW\ 8.5
find . \( ! -user root -o ! -group admin \) -type f -exec chmod 0664 \{\} \;
find . \( ! -user root -o ! -group admin \) -type d -exec chmod 0775 \{\} \;

Maybe fixed in LV 8.6??
-Scott

[TheDillo]

The good news is that the bug has been acknowledged and is in the process of being fixed -- but you're right, it's not fixed for 8.5.

Unfortunately, we're not allowed to divulge when it might/will be fixed.  If I told you, I'd have to ....