Open a "administrator protected" text file from LabVIEW running on standard user

[maxprs]

Yes, I had a look and tried the "RunAs" way calling the ShellExecuteA in the shell32.dll.

It works, but you can only specify the user, not the password, on the command line and this is by design.

I don't know if there is another way to call a exe file from LabVIEW specifying both administrator user and password.

[maxprs]

> Launch the other exe from LabVIEW using the System Exec.vi or .Net

Is there an example about the use of the System Exec vi to launch an exe with administrator rights?

[zou]

---

@maxprs wrote:

> Launch the other exe from LabVIEW using the System Exec.vi or .Net

Is there an example about the use of the System Exec vi to launch an exe with administrator rights?

---

All these methods are the same.  You have to enter the password manually.

This is mandated by Microsoft for security reasons.

[LLindenbauer · Accepted solution]

---

@maxprs wrote:

It works, but you can only specify the user, not the password, on the command line and this is by design.

---

Ah, sorry to have sent you to a dead end there. This kind of underlines that this is really more a system administrator question then a LabVIEW question.

But there are still options left to consider: Using the task scheduler, you can install a startup service that opens an executabe with administrator priviledges. This will not require entering the password again, the credentials should only be required when installing the task. This executable then opens a local socket or pipe that your main executable can connect to. On connection to the socket, reply with the content of the file and reset the connection.

You could even do this over the network: Run this service on a server in the trusted part of the network. As it turns out, this would immediately eliminate the need for the privilege elevation dance on the shop machine, with the added benefit of not storing database credentials on an untrusted machine. That way, noone can simply copy the hard drive and bypass all those elaborate windows user access controls (File encryption would have also helped against such an attack, and also would not require administrator access).

[BertMcMahan]

Do you really need admin rights for the elevation? You could make another non-admin user that has read/write access to the file.

(I haven't tried the above so maybe you can't launch as another user with a different set of permissions)

[rolfk]

---

@maxprs wrote:

Yes, I had a look and tried the "RunAs" way calling the ShellExecuteA in the shell32.dll.

It works, but you can only specify the user, not the password, on the command line and this is by design.

I don't know if there is another way to call a exe file from LabVIEW specifying both administrator user and password.

---

There is but it involves calling Windows API functions that are anything but trivial to call (and to figure out). Microsoft made it intentially very hard to do so, as they do not want Joe Average to circumvent the password protection by creating a batch file or similar to launch admin process tasks by putting the password out in a batch file. Any protection you can easily circumvent is bad protection.

Of course there is the root cause question. What does the customer try to protect here really when he has the text file locked down like this but he also wants the application that needs to read this be operated by Joe Average too.

Maybe it would be time to reconsider the whole requirement or approach. Why has that to be a file? Could it be rather stored in a database? Or requested from a web service?

[maxprs]

> Do you really need admin rights for the elevation? You could make another non-admin user that has read/write access to the file.

That does make sense... only you have to setup another user just for that.

The idea of a file is what it is,,, just an idea; they are usually easy to handle, but with this restrictions I agree that we may need to reconsider the approach.

Something like a web service, or whatever my application can access to get the data required would be fine.

If we want to keep local, it's easy to setup a TCP listener, and if it can be a Windows service (never done before) that can run with full rights, my application will act as the TCP client when it's time to ask for the data required.

Again, the customer is free to create this listener on a remote machine the way they want.

I really thank everybody for their suggestions; this forum is a really a great place to find a lot of help.

Max

[LLindenbauer]

@maxprs wrote:

If we want to keep local, it's easy to setup a TCP listener, and if it can be a Windows service (never done before) that can run with full rights, my application will act as the TCP client when it's time to ask for the data required.

Again, the customer is free to create this listener on a remote machine the way they want.

Giving them the option to change later sounds like an excellent idea.

I don't have a manual on windows services ready, but they are not super complicated - check e.g.

https://stackoverflow.com/questions/3582108/create-windows-service-from-executable

In a pinch you could also try the Windows "Task Scheduler" - it's installed by default and gives you a nice graphical interface.

Good Luck!

[maxprs]

Vero good... thanks again!