password protection option for Locked VIs (read-only VIs)

[Nate_Moehring]

Currently the Protection options are Unlocked, Locked, and Password-protected.  I'd like to add a sub option to Locked, or perhaps a new option altogether that still allows you to view the diagram but not edit the VI unless you have the password.

I want to allow people to run and view all parts of the VI, but not allow them to make any changes to the VI unless they have the password.  This is one step above Locked and one step below password-protected which does not allow the user to view the diagram.

This is useful in an internal environment where you have many LabVIEW-savy users who want to look at how things work, but you still need some level of configuration management and you don't want to allow them to modify VIs.

To make this idea work and meet our needs NI would need to add support for two passwords:  One that prevents the user from modifying the VI and seeing the diagram (the current password-protected option), and a new password that prevents the user from modifying the VI but allows them to see the diagram and VI settings.  This is because we like to be able to debug problems even on a released application so we don't remove diagrams, we just password protect them.  Our release process would utilize both password options.  We would provide the read-only password to users as needed but never give out the modification password.

[AristosQueue (NI)]

> A simple barrier to this behavior is usually all you need.

Like marking the files "read-only".

[Darin.K]

> Like marking the files "read-only".

So I shoud ask all of the users to give up administrative access on the machines in order to use the code?  That is no barrier at all.  Right-click, uncheck.  I have to do it all the time since Windows has a funny way of marking that box when I do not want it.  Might as well just lock the file and say pretty please do not uncheck this.  My users tend to be quite clever it seems, so this is more annoyance than barrier.

Locking a VI in run mode is a simple way to stop all but the serious hackers who probably would be writing their own code anyway.  And by simple I mean simple to implement, not simple to thwart (like read-only files).

[AristosQueue (NI)]

If the read-only lock isn't enough, then I guarantee that nothing LV brings to the table would be enough, because all of our stuff could be circumvented by anyone who replaces the file on disk.

> So I shoud ask all of the users to give up administrative access on the machines in order to use the code?

Yes. If they don't have privileges to be modifying admin level files, they shouldn't have the ability to do so. And any process-critical VIs should be admin level files. This is basic system security. You should have to move into a priviledged mode, consciously and with a password, before you can change system critical functionality.

I can elevate myself to admin authority but I don't have it on at all times, and that's on my personal machine. On a system machine for any industrial facility, I would expect that most operators would not have that authority. If you haven't secured the file system, there's no point in securing the block diagram.

[Nate_Moehring]

There is if the same code is being delivered to both internal and external customers.  I have to hide the diagrams from view for external customers, so I use the existing password option.  But I'd like to allow internal users the ability to view the code (without modification), without creating two distinct builds, and without distributing our password to all internal users (undoubtedly passwords would leak to external users).

You've argued the case that the controlling the VIs show be done through the OS, but if my VIs are already locked to protect IP from external users, then how can I give internal users easy access to see the code?  Yes, they could go to SVN, yes we could publish screen shots to an internal file server.  Neither are convenient.

[Darin.K]

Why would it matter how secure the file system is if LV can be set to ignore it?  I may not be able to save a read-only VI but editing it is only a checkbox away.  Then it is even better, tinker, crash LV and the system, no saved changes, no evidence.  Call me up and try to blame my code.

We are not all large industrial clients (although I guess they butter your bread so that is your perspective), locking a VI in run mode is absolutely perfect for my applications.  It is an easy measure to add, circumvents all but the extremely malicious hackers, OS agnostic (physicists do not deal well with less than admin authority), and provides a full view of the code.  Look, but don't touch.

I guess I understand ambivalence, I do not understand the hostility towards this idea.  There are applications, certainly in laboratory situations, where it is important that the code is fully open for inspection.  Not a copy of the code, not a picture of the code, but the actual code.  It does not, however, have to be open for changes.  LV makes this harder than it needs to be.  I do not need to keep NSA out of my code, just some clever, sometimes impatient students.

If someone replaces a file, that is easy to spot, and it is easy to assign blame.  The latter being the important part. 

[Manzolli]

I can see an application for the concept. If debug is allowed, the costumer can make some testing. With his help, I can figure out a solution, build another VI, lock it for edition, save and send it to replace the problematic one.

In this case, I can have some help to find the causes, but not to solve. This make any sense?

[Darin.K]

I have also seen code that I have posted to the forums/community modified and distributed.  I could see the benefits of posting a VI to be used "as is" and with proper credit given in the comments/description etc.

The code would be fully open (I have to make it easy to see, not easy to copy/paste).  If it is reused I know that my references stay intact, and that it is used "as-is".  Nothing like having your code modified significantly, not necessarily for the better, and still having your name attached.

[AristosQueue (NI)]

Maybe it is my text code background, but none of the preceeding arguments make any sense to me.

Darin.K's post about posting to the forums... If you post some large hierarchy, why force me to duplicate all your libraries/VIs by hand just so I can edit it? If LV had this feature, we'd have to have some sort of "Save As a duplicate hierarchy, stripping the password even though you don't have the password" in order to make it useful, and as soon as we did that, you're right back to your original problem. This is the same issue as a text code file that you post to the web. It's an issue to take up with whoever posts the duplicate. And if I'm that unethical to not note that "this is modified from the original", then I might just as easily write some totally other VI and then attribute it to you.

A couple of you noted that a copy is not acceptable. When an EXE is running, you can't look at the "running C++" code, except as a separate file on disk. Within LV, that's a request that makes no sesne on FPGA or RT targets at all. On desktop, I cannot see any reason whatsoever why it is critical to look at the actual code that is running on the actual deployed machine such that a copy or picture of "that which was deployed" is not sufficient.

Manzoli suggests the "ask user to help you debug" aspect. No, that makes no sense to me either. The deployed code doesn't have any debug capabilities. You strip those out for the massive performance and memory footprint reductions. OR you're deploying a version that still has debug capacities enabled and you're using remote debugging. No network? Then send your customer a version of the code that is unlocked, because to do debugging they're generally going to need to do things like drop new indicators on wires or set breakpoints or otherwise edit the VI. OR you instrument the code beforehand and all they need to look at is the front panels (again, you're sending them a custom build that leaves all the front panels in).

Nate wants to avoid two different builds... but then he lists the internal build and the external build, one where the diagrams are visible and one where they aren't. Seems like there'd still be two builds. Did I misunderstand something? As for this statement: "Yes, they could go to SVN", why isn't that convenient? Whether you download the .zip file or pull from the SCC repository, that's how the vast majority of the world's programmers would look at the source code for a deployed application. And SVN seems pretty convenient to me to make sure that I'm looking at the exact right version of the code, including all the explanatory text in the change logs to help explain that code.

Hostility? That's overstating it. I just see it as a complete waste of R&D time for a feature that serves no useful purpose.

[Nate_Moehring]

We only do one build (with debug features left enabled), but we have two different types of customers.  Internal customers and external customers.  We don't want the external customers to be able to see the code, we don't want the internal customers to be able to see the code (including flipping through case structures), and we don't want either to be able to modify the code.  We do however, want to be able to modify the code locally in some cases if our team is called in to help debug something.  Yes, we sacrifice the memory used by leaving debugging enabled just in case we need to debug something locally.  Often this is on a machine with no access to SVN.

[Manzolli]

I some cases only the costumer has the hardware, so a considerable amount of work is done in site. In many cases we develop the whole system at “home” and deliver to the costumer in another city, estate, country. When support is needed, the client can be hours, sometimes days far from us. “No network” happens sometimes due to companies policy or in isolated places, like some small hydroelectric power plants.

Sometimes the development processes continues on site with a copy of LabVIEW purchased by the costumer. Up to a certain level we don't want him to change or even see the code. Above this level the costumer develops his high level application, change interface, update calculations, create new reports, etc. Using this strategy we can be sure that the wrong parameters will not be sent to the hardware, because the lower level VIs are locked and well constructed to assure that “the hardware rules are being respected”. This is very common with cRIO hardware, where the host (Windows) software is mostly made by the costumer and me, RT and FPGA only by us.

Creating the “view but not change mode” we can allow the programmer turn on some debug features, like “Highlight Execution”, create probes, etc. In this case he can change (see and even mess up his code) part of the code, see what's going on in some VIs (interface between my his and our code) and not see or change a crucial part of the code (our code that has some “secret danger” algorithms).

To implement this, two passwords can be used to achieve the new extra level of protection: one password that allow the user see the block diagram, but not edit it (new password) and the other that blocks edit and see (current password).