LabVIEW Idea Exchange

cancel
Showing results for 
Search instead for 
Did you mean: 
0 Kudos
Spectre_Dave

Set vi to run as admin

Status: Declined

Any idea that has not received any kudos within a year after posting will be automatically declined. 

I have had to jump through hoops to create a .net process or use runas to get portions of code to run

when the end used does NOT have admin privileges.

 

Add Option under VI Properties >> Execution to allow setting the VI to run as admin or another user.

Visualize the Solution

CLA

LabVIEW, LabVIEW FPGA
15 Comments
JackDunaway
Trusted Enthusiast
Intaris
Proven Zealot

Huge security problem.....

 

The user can always set the program to run as administrator if required, the code (cannot, should not) won't.

Spectre_Dave
Active Participant

Yes, it could be a security problem.

 

This attribute should only be visible if logged in with Admin rights.

Visualize the Solution

CLA

LabVIEW, LabVIEW FPGA
Intaris
Proven Zealot

I disagree with Spectre Dave.  I don't think it should be an option at all and I'm not sure is CAN be an option.  If a user does not have admin rights, he should not be able to run an admin process.  I assume most modern OSes will freak out at the attempt to do something like this.

 

If the VI does something which requires admin rights, it should inform the user as such and the user can choose to start the program accordingly (If he has the rights to do so).

Spectre_Dave
Active Participant

This is a MAJOR problem in LabVIEW.  Our products are Ethernet based  - which require the use of Sockets - which requires ADMIN rights. We do not give the test people Admin rights  for security reasons. Therefore I have to create a process that does have ADMIN rights so we can test our products.

 

I am suggesting a special class of VIs that inherit Admin rights for these special situations.  I realize this can open security holes but so does the the method that I am currently using and other work arounds that I have seen posted. This is already allowed in .net and I use .net constructors in LabVIEW to create an Admin process. I am simply asking for an easier way to run Admin processes.

Visualize the Solution

CLA

LabVIEW, LabVIEW FPGA
Intaris
Proven Zealot

And creating a seperate EXE which runs with admin rights isn't viable?

 

Otherwise you just run the entire EXE with admin rights by setting up the "Run As" options.....  I don't see how or why this should be a VI option.

Spectre_Dave
Active Participant

I can not create everything as an .exe because I distribute this as libraries.  As for Runas - I tried that that but it always stops working because of the "patches" that our IT depart pushes out.

Visualize the Solution

CLA

LabVIEW, LabVIEW FPGA
Intaris
Proven Zealot

Don't you see the problem (aside from the fact that I think what you want to do might not be possible) with overriding system security systems?

 

Normally, the resitrictions placed on user accounts are there for a reason.  How do the mentioned .NET systems deal with this?

Spectre_Dave
Active Participant

You don't get it. 

 

Please see the MSDN site to see what I am asking for. Process.Start Method

 

I do this already with .net constructors

21235i5719D7935131DBB8

Visualize the Solution

CLA

LabVIEW, LabVIEW FPGA
Intaris
Proven Zealot

Firstly, obviously I don't get it because I haven't understood what you were on about until now.  Now that you've actually posted an image of what it is you're talking about there is a slight chance I might eventually get it.

 

The code you show runs an APPLICATION as a certain user.  You can do this already in LabVIEW via System Exec.

 

I thought you wanted this in a VI for VI level.......  What I could envisage is that whenever LV encounters a permission problem when executing code it should automatically request a new username and password to execute the code instead of raising an error.  This I could support wholeheartedly.

 

It might be technically difficult to start a single VI as administrator within the LabVIEW process, because this would have to essentially be a seperate application instance AFAIK....