What is server.tcp.acl in ini file?

[MrQuestion]

I'm trying to figure out the purpose of the server.tcp.acl key in a ini file.

We are running labview 8.6.1 and I can't seem to generate this in the ini when creating a build.

I've read some hints in other forms that this ini key might be obsolete and should be removed.

If the server.tcp.acl key is still used, then what purpose does it serve when we can control access via server.tcp.port and server.tcp.access?

This key was generated many LabVIEW versions ago, and is now part of a ini template that we use in our build configuration. 

When I disable the ini template option in the build configuration I no longer see the server.tcp.acl which lead me to believe that we no longer need this.

Can anybody shed some light on this topic?

Regards,

[RavensFan]

I believe ACL stands for Access Control List.  I think you can enable or disable other machines from being able to poke in and control your application by way of VI server.  It's possible it is a part of the DSC module, or maybe it's not.

I've never messed with it, so I don't have any other insight beyond that.

[Ben]

ACL = Access Control List (I BELIEVE)

It describes which VIs are served and optionally to who.

At one pointe in LV history there was bug that failed to properly implement that setting in a built app and we had to transfer it manually to use VI server.

Ben

[MrQuestion]

Is this key still generated when creating a default build of an application?

I've tested on my system and it doesn't show up. 

But, it's possible that this ini key will only show up if something is modified in the tools>>options>>??server??  configurations.

If it's there to define what machine has access to what VI, then what the heck does the 

server.tcp.port
server.tcp.access

[RavensFan]

Some interesting links.

http://digital.ni.com/public.nsf/allkb/DCFB5E8D9D658F2586257832006093E2

http://forums.ni.com/t5/LabVIEW/How-do-I-generate-quot-server-tcp-acl-quot-entry-for-built/td-p/3580...

The default build of an application seems to give these lines in the .ini file (at least this is what I got when I just built an empty project with an empty VI.)  This is in 2016.

It doesn't seem to give any of the server.tcp.acl    .port or .access items.

[Application]
server.app.propertiesEnabled=True
server.ole.enabled=True
server.tcp.paranoid=True
server.tcp.serviceName="My Computer/VI Server"
server.vi.callsEnabled=True
server.vi.propertiesEnabled=True
WebServer.TcpAccess="c+*"
WebServer.ViAccess="+*"
DebugServerEnabled=False
DebugServerWaitOnLaunch=False

[MrQuestion]

I did find this in the labview help. 

https://zone.ni.com/reference/en-XX/help/371361N-01/lvpage/pp_security_db/

I did verify if I add a ip address or name to the list of approved machines the server.tcp.acl key is populated. Left to default the acl key is not used.

It seems a bit confusing to have a encoded ACL value; as in no human readable. I always thought it was out of scope of an INI file to have non human readable values in it.

Why not just have a list of names.

[Ben]

If you modify the VI Server access list the changes should show up in the ini file for LabVIEW. You can use those as a guide to see how the entry should be formatted if you want to serve VI inside an exe for access from another machine.

Ben

[MrQuestion]

Ben,

I noticed your wording 

---

---

if you want to serve VI inside an exe for access from another machine.

What if I will never run an exe on another machine to access VI's from a different computer.

This acl setting in the INI was inherited to me. In our deployment directions it says to manually insert the acl settings in the INI file. Our directions were written many years ago and I am the first one to question 'why?'.

We do have real time systems running and some of them use VISA server. Does that count as one exe accessing a VI from another machine?

I never knew that you could run an exe on one machine and launch a VI on a different computer. That sounds kinda cool, but I don't think our code is doing that. 

I would like to just remove the settings and see how the system runs. But, our applications is massive and could take months or even years before we find an issue because of some fringe application case that I wasn't aware of at the time.

I can tell you that this system is on a private network that only has one pxi windows chassi and multiple real time systems.

Do I even need an acl server setting in this case?

[Ben]

Good question MrQuestion!

I can not speak with certainty. I am "only the user of the thing and not the maker of the thing". (see The Republic Chapter X)

What I can say is that RT applications developed back in the LV 6i period often used VI Server to enable Windows control of the RT application. It was "the right way" to allow remote control. Using VI server then was  no-brainer once you got past figuring out what the path on the RT machine was once the application was built.

Then time past and someone decided VI-Server could be exploited as a security risk. I remember reading a post by Jean-Pierre Drolet that told the story of arriving at work but forgetting critical file on his machine at home. He knew the IP address of his machine so he opened a seesion to LV on his home machine from his machine at work and then invoked to use d a Call By reference node to invoke the file read of the critical file and returned the contents to his work machine. Very clever but as I mentioned, a security hole for those that knew LV.

NI then added the ACL stuff and the associated set-up screen. Then my use of VI server got more complicated and I had to remember to set the access of served VIs. Time past and then I found myself working with Mike Porter who was having trouble making the VI server connection and we latter found that LV was not transferring the ACL setting to the ini of the built app.

To finish this bit of history I latter discovered the ACL control stuff has now been moved into the project.

So I can say the ACL did make a difference for VI Server. How far that reach extended beyond VI Server... NI is going to have to answer that question.

As for your situation...

1) If you have a active accout with NI I would log a service request and see if you can get a formal answer as to what aspects of LV are affected by the ACL.

2) Get a complete list of all of the functionality of the application that you are supporting and establish test criteria to test all of that functionality.

3) Wipe out the "acl" settings and then run through your test regime. If you broke something, put it back.

That is all I can offer. Please report any interesting finding that you discover so that rest of us can learn from your experience.

Ben