/usr and /var can only be written by admin

[Staab_Engineering]

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

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. 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.

[BradM]

The reasoning is to prevent a poorly-written (or malicious) LV application from damaging the system (as /usr and /var contain important system libraries, binaries, and files).

Any particular reason you want to create those folders at those locations? Any more details on their use beyond a "shared folder and a working folder"? Traditionally, the user's home directory is used for this purpose unless there's a good reason to allow access from other users on the system. How, where, and by which users are the contents from these folders to be used?

[Staab_Engineering]

I want to put files that change frequently in /var/local because that's the standard *nix path for such things. I don't want to put shared files in /home/lvuser because I don't want other binaries to have to know who made those files in advance. (I want them to just look in the standard path for shared things and see if the desired file is there.)

<rant>

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. It often feels like I'm trying to use a kid's toy for adult work.

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.

</rant>

[Daklu]

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. It often feels like I'm trying to use a kid's toy for adult work.

I have to agree with Staab on this point.  It's been a source of frustration for me for several years.  I understand the vast majority of the LV user base are not professional software developers and I get the business decision being made.  Still, as an advanced developer it's aggravating to constantly have to figure out ways to get around the walls NI has built to protect the average user.

Just my $.02.

[gratian.crisan]

Having /usr and /var be owned by 'root' (i.e. admin) is the de facto standard in the *nix world. For example this is the listing of a Linux Mint box I have around:

     drwxr-xr-x  16 root root   4096 Sep 23  2015 usr

     drwxr-xr-x  15 root root   4096 Sep  4  2014 var

There are multiple reasons why unprivileged users don't have 'write' rights to these folders: security, system integrity, users stepping on each other toes etc.

Having said that; we are talking here about an embedded system so the expectations might be different (multiple users are not common): Are you asking why LVRT doesn't run as the privileged user 'admin' instead of 'lvuser'?

[Staab_Engineering]

I'm definitely not asking that. I'm asking why LV has no way to create folders in /usr/local and /var/local. Put sudo in our distribution, or add lvuser to a group that has more rights, or add an escalation request protocol to NI-Auth, or...whatever. Just let me work on my embedded, single-purpose device the way I want.

[ScotSalmon]

Your comment is timely: we agree that it's problematic that LV doesn't have an easy way to sudo out of the box, and we've been actively discussing how to improve that. Can you elaborate on why you're "definitely" not asking for lvrt to run as admin? (Spoiler alert, I agree with you, but I'm a little surprised you feel so strongly about that.) FWIW sudo is in the opkg feed (opkg install sudo). After installing it, you can add lvuser to /etc/sudoers and not require a password ("lvuser ALL=(ALL) NOPASSWD: ALL"), and then you can use sudo with System Exec.vi to do what you ask. But that's not the user-friendly experience we'd all like to see, obviously.

As far as the actual path to use: if I am reading correctly, when it comes to where to put these files, their most relevant attribute is that they are shared between programs. The fact that they change frequently I think is probably secondary, is that correct? If the goal is to share them without respect to the user that created them, have a look at the suggestions here: http://unix.stackexchange.com/questions/70700/whats-the-most-appropriate-directory-where-to-place-fi...

Their suggestions, which make sense to me, include /srv (a path we don't create by default, so you can set up however you prefer), and /home/<purpose> with the observation that /home need not be just user directories but could be directories for projects, teams, groups, whatever (though this is qualified with "on large systems" in the standard and seems less appropriate here).

[Staab_Engineering]

I wanted to distinguish between what I'm asking for and what it was suggested that I'm asking for. Just making sure my question wasn't replaced by another. If adding lvuser to the administrators group is how to want to solve the problem, go for it. For my part, I think there are too many exploits out there that can get a proc to run injected code against its will, so making that proc an admin leaves an open door to causing trouble. On the flipside, LV has so many gotchas and unexpected limitations that I've made it a policy not to expose it directly to any outside connection, so it's less of a concern to me. (By decree, a LVRT app must work thorugh a reverse-proxy or broker whenever feasible.)

Those are solid suggestions, and I've definitely seen /srv in some apps. I try to stick to the default *nix structure as much as possible so any dev can reasonably easily find code or config when he needs to. The fewer possible search paths, the faster someone without a full Developer Manual in hand can find it. (Nobody writes or updates the Developer Manual, anyway...it's varporware.)

[BradM]

Staab_Engineering wrote:

I want to put files that change frequently in /var/local because that's the standard *nix path for such things. I don't want to put shared files in /home/lvuser because I don't want other binaries to have to know who made those files in advance. (I want them to just look in the standard path for shared things and see if the desired file is there.)

<rant>

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. It often feels like I'm trying to use a kid's toy for adult work.

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.

</rant>

What you perceived as hubris-filled dismissal was a geniune question. I see how what I said could be taken in the wrong way, and for that I'm sorry. NI does listen to advanced customer's requests, so your rants aren't simply ignored.

Back to the issues at hand, generally speaking, when a daemon needs a folder created in this location, it's created on installation. Installation is not synonymous with deploying (either interactively or as a startup application) some G. I think the issue here is the general disconnect with a LVRT app running on the target (even a startup application) and the notion that it would be a daemon that is controlling or monitoring the system as a traditional linux daemon. As the system behaves currently, you could view G code execution (including startup applications) as an application being run as a normal(ish) user instead of a daemon.

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. 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.

[Staab_Engineering]

BradM wrote:

I think the issue here is the general disconnect with a LVRT app running on the target (even a startup application) and the notion that it would be a daemon that is controlling or monitoring the system as a traditional linux daemon. As the system behaves currently, you could view G code execution (including startup applications) as an application being run as a normal(ish) user instead of a daemon.

The LVRT startup executable is neither controllable from a terminal nor run temporarily. It's designed to start with system boot (as if by placement in init.d and rc.d) and keep running until it fails or the system is shut down. All of this inclines me to design my LVRT code to run as a daemon. And I want that: an embedded Linux device -- especially a headless one like most cRIO/sbRIO apps demand -- is going to use a bunch of daemons to get its work done.

If you want my LV code to be treated as a normal app run by a normal user, give me control over the LVRT process/es so I can run apps from the command line, stop and restart apps, run multiple apps concurrently, etc. Without this power, the only functional way to design an LVRT app is as a daemon.

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.

Understood. That still means I need a way to "install" my LVRT app on the system with elevated privileges. I don't have that with the LV IDE, nor do I have a way to install it with shell scripting or a package manager. So I'm trying to bootstrap the folders from the app as I've described.