/usr and /var can only be written by admin

[ScotSalmon]

If the goal is primarily to enable your LVRT app to share data with another program/userid in a specified shared directory, you can create such a directory and give LVRT the necessary access permissions to it. You can do that part with shell scripting and/or use of sudo like we discussed above.

If the goal is  to give LVRT elevated privileges in general, for example because of other cases (besides sharing a file with another program/userid) that you anticipate in the future, you can modify the shell scripts that give LVRT its permissions. For example you can modify /etc/init.d/nilvrt to start LVRT as admin instead of lvuser, or you can modify the http://man7.org/linux/man-pages/man7/capabilities.7.html of the lvrt binary to grant it the capability you need (like CAP_DAC_OVERRIDE) along with the others it has.

You can use a CDF (either a new one that patches the default, or modifications to the default) to install the modified shell scripts if you want this to persist across reformat/reinstall or to new controllers.

I realize the suggestions above are not exactly intuitive and we can do better. As I mentioned we're actively discussing, researching, and even working on these issues, including ways to accomplish sudo-like behavior and/or capability control natively in LV, and to start LVRT built apps as separate native executables. But the ideas above might get you un-stuck in the meantime.

[metux]

---

@Staab_Engineering wrote:

The rights on /usr and /var are rwxr-xr-x with owner admin. Why is that?

Actually, it should be owned by root.

Elementary Unix security. Arbitrary users should only have full write access to their homedir, unless the operator (which hopefully knows what he doing) gives them other permissions explicitly.

Refer to the Unix beginners book of your choice.

I want to create a shared folder and a working folder for lvuser at /var/local/shared and /var/local/lvuser, but my LVRT app can't do that.

 Has to be done as root.

No way to automate the fix via LV code either, since I can't execute it as admin. Seems like I'll have to connect with another tool like SSH/SCP/FTP and run a script to change the permissions.

Correct.

For automatic deployment, you should put it into an ipkg package (same w/ your application)

[metux]

Staab_Engineering wrote:

It's frustrating that you guys chose (again, as with so many baffling constraints I find working with NI tools day to day) to hamper competent users of your product in the interest of stupid-proofing it.

ACK !

Even worse: they try to hide users from vital things, especially when it comes to security and stability. Thus preventing them from learning the necessary elementary skills to maintain such machines - especially w/ IOT, security is absolutely vital !

We cannot tolerate power plants being remote controllable by scriptkiddies - w/ automobiles it's already bitter reality.

Unix machines just aren't PLCs - you cant treat them as such w/o causing great damage.

It often feels like I'm trying to use a kid's toy for adult work.

Actually, that are kids toys - they're using proprietary kernel modules !

When you -- literally any NI employee I interact with, be it sales R&D or support -- challenge my reasons for wanting to design software a certain way, it doubles the effect. Your company's culture seems to be imbued with the belief that you know what's best for software developers, and if they challenge your assumptions, they must be doing something wrong. If an individual acts that way, he's labeled a narcissist.

Properly trained sheep are happy within their fences and scared by the outside.

[metux]

BradM wrote:

NI does listen to advanced customer's requests, so your rants aren't simply ignored.

Well, if you're loud enough, put enough tobaco in the wound, they actually listen.  

But that doesn't necessarily mean you'll get anything helpful. For example w/ the proprietary kernel modules - which make the product entirely useless for decent industrial linux applications (outside small PLC-world fences). But they advertise it for exactly that.

If NI just wants to sell them as LV-programmed PLCs, fine. But then at least they should be honest and responsible by not advertising them for Linux applications anymore.

The point that really makes me angry is that they're just making false claims here, and it's people like me, who have to explain our clients that these boxes aren't usable for Linux applications and NI's PR is wrong. Often they already invested a lot into the wrong direction, just because such false PR. 

Installation is not synonymous with deploying (either interactively or as a startup application) some G.

This is exactly how deployment in Linux world is NOT supposed to be done. Thats what package managers have been invented for. (and are now widely proven for decades)

The behavior noted here would be an issue for any development system, python or perl running as a normal user would be unable to create system-level directories.

Exactly the reason why they're properly packaged by the distro.

(yes: certain script language communities, eg. ruby, are quite hostile against distros and packaging, as w/ any decent release engineering and operating methods - that's the reason why their applications are highjacked so regularily)

A daemon written in either of these languages would require that there be some initial setup to create the folders in protected areas, in the case of software installed through the Linux distro's package manager, these folders would be created as part of the installation process. For applications that are being developed, they would require the same level of consideration and configuration that is being experienced here.

Exactly. In Embedded Linux world, we naturally have only daemons.