Before I open my big mouth and say it is the default way a console app works in c# I wanted to get a few of you folks opinion.
Essentially, we have a c# console app the create a folder full of files from byte streams. Pretty simple. They now want to have it write directly to a shared drive that only a few people have read/write privilages.
I think that as long as they kick of the exe while logged in as as privelaged user it will copy to the share drive.
Unfortunately, they want this information without creating the folder and share first. sigh b/c that would have been too easy to just test the blasted thing.
To answer the question in the title of your question, yes, a C# console app runs under whatever account you run it as.
Note, you should be able to right click on the executable and click "run as" or "run as administrator" instead of actually logging on as another user.
I hope I'm not missing the point of your question.
By default, yes, it will run under the logged in user credentials (as would any other application).
Of course, if this is run as a scheduled task, uses the Process class or the runas command, one can specify a different user.
If you open task manager, you will see the process owner in the "User Name" collumn.
Any application run without specifying a specific user (Run as...) runs under default logged in user's context.
Related
I need to develop an application that will run on clients. The main focus is to let the application update another -specific- application and be able to monitor own defined states for clients. I'm considering something like a console application with TopShelf because it makes debug a lot easier. However... to install or update this specific application I must use a MSI. But if for example I create a process that executes msiexec the client/end user will be prompt with UAC. This is a big issue because clients should be updated unattended. And UAC must stay the way it is : highest level.
I've read a lot of questions/answer concerning UAC prompt... and to be honest I'm starting to doubt my own approach. I was not able to find any question that I could relate to.. so I would appreciate it if someone could give me some good advise, tips, references etc on a possible way to approach this issue.
Thanks in advance
Create a Task Scheduler job with the "Run with highest privileges" option checked.
You can easily create this job programatically, even using a XML configuration file.
This way the user is prompted to allow UAC only once (when first clicking an exe for example).
Say I have a simple C# monitoring program that is to be installed on some company computers, so I know what the employees are doing. The program is a single .exe file that works in the system tray. How do I prevent employees from closing this program? Is there a way to be notified when a program is closed?
If you don't want users to close your program, run it under a different account. Normal users can't kill processes they don't own, ie that run using different accounts. Of course, this means that you can't run your program as a simple application that displays a taskbar notification. You will have to convert it to a service.
In fact, a service makes a lot more sense than a user application in this scenario. If you want to display feedback or options to the user you can still create an app that creates a taskbar icon and communicates with your service
Set it up as a service and in the options for the service on first, second, and third failure - make it reboot the computer. Have the service login-as an service user with a strong password and prevent the users from running as Administrators. This should solve your problem and probably create a bit of annoyance at the same time.
The short answer: No.
The long answer: Yes...write a rootkit which will either guard or hide your process. Otherwise the users will be able to kill the process f.e. via the Task-Manager or any other means. Same goes for any helper processes which would monitor your application.
i've created an setup project for a .net-application which works fine. The problem is, that the application begins to write log-files after startup and this requires administrative rights on windows vista and windows 7. I know there are some folders which i could use to write into without administrative rights. When i start the application as administrator, everything works fine.
I asked myself, if it's possible to change the setup project in visual studio in a way that the installed application automatically owns administrative rights on the target system?
Thanks for every help in advance!
Alex
You don't want to do this. If it needs rights to a particular directory, then create an account that has them (or modify the subdirectory's rights so that anyone can access it). But don't run as admin just for one feature. Also, look into whether there's another directory you could be writing to, which you already have rights to.
To answer your direct question, yes you can setup a launch condition for the setup project to require administrator, I believe this will take care of the proper escalation for you.
here is a thread with detailed instructions.
Now, to expand, I agree with Steven that you SHOULDN'T do this, at least not just to be able to write a log file.....
You could technically do this with a bad hack: The idea is to have the Setup program which runs elevated create a scheduled task that runs the program as admin.
Instead of directly creating a shortcut to your application, the setup creates an shortcut to execute this scheduled task.
See this as reference on how to do that manually: http://www.howtogeek.com/howto/windows-vista/create-administrator-mode-shortcuts-without-uac-prompts-in-windows-vista/
You just need to find a way to create the task programatically from your setup.
On the other hand, I totally agree with Steven too. Try to do it the 'right' way and don't trick the Windows security. It's a good thing and working around it makes the system potentially unsecure, and you don't want to be the one compromising tht Security of others computers.
Has anyone managed to get administration rights through the UAC without restarting the application or embedding a manifest file?
I'd like to write to some files that only administrators can modify, without relying to another elevated application. Is it possible to impersonate an administrator previously calling with some native API the UAC prompt?
I guess this is not possible and I'll have to use an external tool with elevated rights, but I'm asking just in case.
EDIT: I know there are some other similar questions around, but since they do not cover the topic of impersonation (as fas as I've seen), nor some possible native call to the UAC prompt I decided to give a new thread a go...
As stated in this other question, it is not possible, you have can eleveate COM object or another process, but not the current process.
Request Windows Vista UAC elevation if path is protected?
I read that thread (along with a lot more heh), but you never know what other people has managed to do recently. And maybe the release of SP2 changed something, dunno.
Well, I guess there are no changes on how the UAC works nor any discovery on workarounds, so I'll mark the previous answer as the right one.
I'll make another application that performs the administrative tasks I need.
Thank you.
If all you want to do it get admin rights without a manifest (ie: im assuming you're not talking about cracking/hacking the UAC implementation), then just create a shortcut with the "Run As Admin" checkbox checked. You can programmatically generate this shortcut as long as you look up how short cuts are written (in terms of their fiel contents) and I'm sure there is some name/value pair you will need to include inside the shortcut to ensure that Run As Admin is checked by default. Now, when people run that shortcut instead of your exe, they will get prompted to run your exe in elevated mode (with admin rights), and this way you will not need to restart or use a manifest.
Excuse me if I have misunderstood your question.
Adding a manifest file in the same directory as the executable "works for me". Not actually getting the permissions, but it prompts for the permission.
I need my winform program to run as another user (it will run under task scheduler) and not the logged on user. I suspect the trouble is my app is gui based and not command line based (does this make a difference) so the gui needs to load do its thing and then close. Is this possibly under XP or Vista?
Thanks
Scheduled Tasks can be 'run as' a specified user, which can be different to the logged-in user.
You can specify this user when creating the task, or by editing the properties of an existing task.
If your app needs to run as a sheduled task then it can't really have a UI. As a bare minimum it should really be capable of being run via the command line.
The best approach would be to separate the UI from the actual processing so that the you can still run it interactively if required. This would also make testing your app a whole lot easier.
EDIT: Edited for typing and sense
I'd vote for the first option, or to provide an extra possibility: Use Impersonation in your code. Although it might be overkill/not fit your needs here.
Another way you could execute the program is to Programmatically change the user based on a config file or even a DB connection. One sample project is on Code Project:
http://www.codeproject.com/KB/cs/runas.aspx
Hope this helps.
You're looking for the Process.Start method. One of the overloads accepts a user name / password pair. The process will be created using those user credentials.
var app = Process.Start(#"c:\path\to\some\app.exe", userName, password, domainOrEmptyString);