We are building an ASP.NET API running with .NET 5 that uses SkiaSharp to dynamically create and return images. We've noticed that using the GPU has a dramatic increase in performance. We know that in order to use the GPU we need an OpenGL Context instantiated, but with it comes some requirements. Our tests work well in our environments: Mac and Windows, but doesn't work when deployed to the Linux Azure App Service using P1v2 VM.
The error message Unable to create GL context: Unable to load shared library 'libX11'. Doing some research I realized the container doesn't have OpenGL installed and trying to install it through apt-get is not possible because of lack of permissions.
I went the route of running the KuduLite container locally in my machine and installing libgl1-mesa-glx and mesa-utils, but running glxinfo results in the error Error: unable to open display. I found this blog post that explains the requirements of running hardware accelerated OpenGL support in Docker. The blog post is from 2014 so I'm not sure if it is still valid, but if it is there quite a few requirements that before I try to solve locally in my machine I would like to know if they are even possible in Azure App Service Container.
So, is it even possible to have hardware accelerated OpenGL support in Azure App Service docker?
The problem you're running into is, that the machine you're running this on is headless and doesn't run a X11 display server. Most application-frameworks-for-use-with-OpenGL assume that they'll be running in some interactive graphical environment, i.e. having either an X11 server (which is configured to use the GPU) or a Wayland compositor around.
glxinfo doesn't have to do anything about this, BTW. It's just a little tool to query what kind of OpenGL capabilities a given X11 display (server) has. If you don't run X11 in the first place, you don't need it.
Up until a few years ago, this in fact was the only way to get GPU acceleration on Linux. Luckily those days are long gone. These days one can obtain fully headless, offscreen OpenGL contexts using EGL. Nvidia has a nice blog about how to do it:
https://developer.nvidia.com/blog/egl-eye-opengl-visualization-without-x-server/
Then there's this Github repo:
https://github.com/eduble/gl
You'll get the idea: Instead of opening a window you get a so called "surface" and draw on that.
With Vulkan it's even more straightforward, because you don't even have to bother setting up a surface suitable for pushing to a display if your goal is rendering an image to a buffer that you wrap up in a file or send out over a network (look at the offscreen sample in Sascha Willems' examples https://www.saschawillems.de/creations/vulkan-examples/)
I'm new to programming. There are quite a lot of Q/A on this, but I couldn't find a concrete answer. Hence the question. I'm writing a screen sharing application. Now I want to turn that application to windows service. which I already did with. Apparently, the application works like this. When the counter party sends the screenshots, the application receives it and parses the data to RGB and shows on a window renderer. Because now its a service, although it receives the data, i believe that it may not be able to open renderer in the current desktop due to session isolation, the way to get around this would be to use IPC between Desktop App an the service. However, it makes it complected. Is there any simple way to solve this problem?
Is there any way to use hardware accelerated OpenGl from a Windows 7 Service?
The normal Session 0 has no access to the graphics card driver.
Is there any way to configure the service that this is possible (e.g. specify user)?
I´m aware that there are possibilities for starting a new process, but using IPC would render the whole purpose of using hardware acceleration useless.
i also checked this SO questions, but it also creates a new process.
What would be the simplest way for an application I'm writing to block all Internet access on a Windows machine?
More details:
Windows: XP or higher
Application: A basic Win32 app written in C/C++.
Blocking: It needs to be able to block and unblock at will, ideally in a way that the user can't easily reverse. (By, say, right clicking on a network connection icon in the system tray.) Also, ideally, I'd like the method it uses to allow access to be restored should the user restart Windows or reset the machine, though I'd also be willing to have the app auto launch with Windows and unblock access upon startup if the machine was reset while in a blocked state.
Internet access: Primarily, I'd like to block conventional browsers from hitting conventional http/https sites. Secondarily, it would be nice to block IM clients and client-side social networking apps. It would also be nice, but not required, to still allow local networking for file sharing, etc. (Note that only the first requirement is absolute.)
Final notes: This is not meant to be a security utility, nor will its relationship to the user be adversarial (as, for example, with a parental control utility) so it's not important for it to use a scheme that can't be worked around by a determined user. (Consider that I intend for a reboot or reset to clear the blocking. This means that any workaround a user might discover that would take more effort than this is okay.)
Thanks!
p.s. I suspect that the Windows Firewall API won't work for me because this needs to work for users that haven't enabled the firewall or don't have admin privileges, but I'll be thrilled if I'm corrected on this.
It sounds like you're intending to run applications that you don't want to access the internet. Perhaps you could run them inside a virtual machine such as VirtualBox with networking disabled.
You could do it with a Winsock SPI. The Windows SDK has a sample (under Samples\netds\winsock\lsp) which implements what is called a layered service provider which allows you to hook all the user mode functions provided by Winsock and reject/modify the calls to block network access or redirect traffic to different locations. All installed winsock applications will be affected, so in your code you could have policys for what applications can go out and the like and disabled/enable on the fly. Now a determined person could find ways around this but it would be a pain.
That said this isn't trivial to do but the sample should get you most of the way there.
You cannot effectively or practically write your tool with only a user mode application.
What you need to write is a network I/O stack filter driver. This done by writing a Windows Driver. This is different from a Windows Win32 application. Drivers run in kernel mode and applications run in user mode.
On Windows Vista and later, the kernel mode Network Programming Interface (NPI) is designed for this. This is the same API that Windows Firewalls use. These are sometimes called the Winsock kernel (WSK) APIs.
In effect, you are writing a network firewall (more or less)
here are some links
Introduction to Winsock Kernel (WSK)
Windows Core Networking Blog
The Network Programming Interface Docs on MSDN
Note, your will likely need at least two components
Your driver
A Graphical application that a person can use to control your tool
If you want to do any monitoring, you will likely need a user mode service that collects data from your driver. This works better than trying to do this in the driver. In general, you should do the minimal amount of work in the driver.
A few notes:
You need to be very conscious of security when writing this kind of software. This is very much non trivial. Software that is network facing has the highest security requirements.
Be cognizant of performance.
Your driver and/or service must be aware of the context of a calling application. This is also a security boundary. For example, an application not running as administrator should not be able to control your driver.
take a look at firewall sourcecodes
I have written a Windows service that allows me to remotely run and stop applications. These applications are run using CreateProcess, and this works for me because most of them only perform backend processing. Recently, I need to run applications that present GUI to the current log in user. How do I code in C++ to allow my service to locate the currently active desktop and run the GUI on it?
Roger Lipscombe's answer, to use WTSEnumerateSessions to find the right desktop, then CreateProcessAsUser to start the application on that desktop (you pass it the handle of the desktop as part of the STARTUPINFO structure) is correct.
However, I would strongly recommend against doing this. In some environments, such as Terminal Server hosts with many active users, determining which desktop is the 'active' one isn't easy, and may not even be possible.
But most importantly, if an application will suddenly appear on a user's desktop, this may very well occur at a bad time (either because the user simply isn't expecting it, or because you're trying to launch the app when the session isn't quite initialized yet, in the process of shutting down, or whatever).
A more conventional approach would be to put a shortcut to a small client app for your service in the global startup group. This app will then launch along with every user session, and can be used start other apps (if so desired) without any juggling of user credentials, sessions and/or desktops.
Also, this shortcut can be moved/disabled by administrators as desired, which will make deployment of your application much easier, since it doesn't deviate from the standards used by other Windows apps...
The short answer is "You don't", as opening a GUI program running under another user context is a security vulnerability commonly known as a Shatter Attack.
Take a look at this MSDN article: Interactive Services. It gives some options for a service to interact with a user.
In short you have these options:
Display a dialog box in the user's session using the WTSSendMessage function.
Create a separate hidden GUI application and use the CreateProcessAsUser function to run the application within the context of the interactive user. Design the GUI application to communicate with the service through some method of interprocess communication (IPC), for example, named pipes. The service communicates with the GUI application to tell it when to display the GUI. The application communicates the results of the user interaction back to the service so that the service can take the appropriate action. Note that IPC can expose your service interfaces over the network unless you use an appropriate access control list (ACL).
If this service runs on a multiuser system, add the application to the following key so that it is run in each session: HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\CurrentVersion\Run. If the application uses named pipes for IPC, the server can distinguish between multiple user processes by giving each pipe a unique name based on the session ID.
WTSEnumerateSessions and CreateProcessAsUser.
Several people suggested WTSEnumerateSessions and CreateProcessAsUser. I wonder why no one suggested WTSGetActiveConsoleSessionId, since you said you only want to target one logged in user.
Several people sure are right to suggest CreateProcessAsUser though. If you call plain old CreateProcess the way you said, then the application's GUI will run with your service's privileges instead of the user's privileges.
That problems Session 0 , Interactive Services ,
Windows Service Allow Service To Interact With Desktop
on Windows 7 or Windows Vista
You can read this article
http://www.codeproject.com/KB/vista-security/SubvertingVistaUAC.aspx
I try explained here it's working on Windows 7
On Win2K, XP and Win2K3 the console user is logged on in Session 0, the same session the services live in. If a service is configured as interactive, it'll be able to show the UI on the user's desktop.
However, on Vista, no user can be logged on in Session 0. Showing UI from a service there is a bit trickier. You need to enumerate the active sessions using WTSEnumerateSessions API, find the console session and create the process as that user. Of course, you need also a token or user credentials to be able to do that. You can read more details about this process here.
I think as long as you have only one user logged in, it will automatically display on that user's desktop.
Anyway, be very careful when having a service start an exe.
If the write access to the folder with the exe is not restricted, any user can replace that exe with any other program, which will then be run with sytem rights. Take for example cmd.exe (available on all windows sytems). The next time the service tries to start your exe, you get a command shell with system rights...
If you launch a GUI from your service it will show up on the currently active desktop.
But only if you adjusted the service permissions: You need to allow it to interact with the desktop.
Important Services cannot directly interact with a user as of Windows Vista. Therefore, the techniques mentioned in the section titled Using an Interactive Service should not be used in new code.
This is taken from : http://msdn.microsoft.com/en-us/library/ms683502(VS.85).aspx