I know that you can't technically chroot a thread, but I'm looking for functional alternatives that would limit the amount of permissions to an existing set of tasks within a thread.
Edit: This is for a Linux environment, however Windows related techniques would be useful as well (even if they have no *NIX equivalent.
There are few differences between threads and processes on Linux. Use the clone syscall with the flag CLONE_THREAD and without the flag CLONE_FS, so that the new thread does not share its root directory/current directory/umask with the calling thread. Alternatively, you can use the unshare syscall with CLONE_FS after the fact. Now you can use chroot as normal and it will not affect other threads in the process.
Setting permissions for a thread in windows is trivial using the impersonation functions in the Win32 API.
I'm not an expert in GNU/Linux system programming so there may be extensions that allow modification of the per thread UID, but as far as I know Unix systems have per process security not per thread as in Windows.
This is because historically Unix has used processes for parallel processing (fork) while Windows uses threads (CreateThread), and (historically?) creating new processes in Unix is comparable in speed to creating new threads in Windows.
I'm giving your question +1 since a cursory Google search seems to indicate the preferred way to restrict permissions is to fork the different tasks to processes by security and use setuid to set the permissions and optionally then chroot them.
I'd like to hear whether there are other options since, as mentioned above, this use case is rather trivial to implement in windows.
Related
If possible I do wish to allocate a logical core to a single process exclusively.
I am aware that Winbase.h contains Get/SetProcessAffinityMask and SetThreadAffinityMask.
I can get all processes running when the specific process is started and set their affinities to other logical cores, however, I do not want to check all processes in a periodic manner, for instance in order to deal with processes launched after the initiation of my process.
Furthermore there will be other processes which need to use specific logical cores only exclusively (no other process shall waste resources on that logical core). For instance my process shall run on core 15 but another shall run only on core 14.
Is there a better and more permanent way to allocate specific logical cores to specific processes than above mentioned Get/SetProcessAffinityMask scheme.
Windows is not a real-time operating system. Windows is designed to do preemptive multitasking with isolated processes, like basically any other modern desktop OS. A process is not supposed to just lock out every other process from a particular core, therefore, there is no API to explicitly do so (at least I'm not aware of one). It's up to the OS scheduler to decide which threads get to run when and where. That's the whole idea. You can use thread priorities to tell the scheduler that certain threads should be given a chance to run over others. You can use affinity masks to tell the scheduler which cores a thread can be scheduled to. You can even set a preferred core for your thread. But you don't get to schedule threads yourself.
Note that there's apparently a way to get something a bit like what you're looking for to work on Linux (see this question for more). I don't think similar possibilities exist on Windows. Yes you could try to hack together some solution based on a background task that continuously monitors and adjusts the priorities and affinity masks of all the threads in the system to approximate the desired behavior (like the person in the question linked by Ben Voigt above has apparently tried, and failed to achieve). But why would you want to do that? It goes completely against the very nature of everything an OS like Windows is designed to do. To me, what you are asking sounds a lot like what you're really looking for is a completely different kind of operating system, or maybe even no operating system at all. Boot the CPU straight into your own image and you get to drive all the cores in whatever way you fancy…
Can a fiber created in thread A switch to another fiber created in thread B? To make the question more specific, some operating systems have fibers natively implemented (windows fibers),
other need to implement it themselves (using setjump longjump in linux etc.).
Libcoro for example wraps this all up in a single API (for windows it’s just a wrapper for native fibers, for Linux it implements it itself etc.)
So, if it's possible to migrate fibers between threads, can you give me an example usage in windows (linux) in c/c++?
I found something about fiber migration in the boost library documentation, but it's not specific enough about it's implementation and platform dependence. I still want to understand how to do it myself using only windows fibers for example (or using Libcoro on linux).
If it's not possible in a general way, why so?
I understand that fibers are meant to be used as lightweight threads for cooperative multitasking over a single thread, they have cheap context switching compared to regular threads, and they simplify the programming.
An example usage is a system with several threads, each having several fibers doing some kind of work hierarchy on their parent thread (never leaving the parent thread).
Even though it's not the intended use I still want to learn how to do it if it's possible in a general way, because I think I can optimize the work load on my job system by migrating fibers between threads.
The mentioned boost.fiber uses boost.context (callcc/continuation) to implement context switching.
Till boost-1.64 callcc was implemented in assembler only, boost-1.65 enables you to choose between assembler, Windows Fibers (Windows) or ucontext (POSIX if available; deprecated API by POSIX).
The assembler implementation is faster that the other two (2 orders of magnitude compared to ucontext).
boost.fiber uses callcc to implement lightweight threads/fibers - the library provides fiber schedulers that allow to migrate fibers between threads.
For instance one provided scheduler steals fibers from other threads if its run-queue goes out of work (fibers that are ready/that can be resumed).
(so you can choose Windows Fibers that get migrated between threads).
I've got a threaded C++ application that runs under Linux, Windows, and MacOS/X (using pthreads under Linux and MacOS/X, and _beginthreadex() under Windows).
In the application, I spawn three threads: A, B, and C. I'd like to make it so that thread A's performance won't/can't be affected by the CPU usage of thread B, and so that thread B's performance, in turn, won't/can't be affected by the CPU usage of thread C.
The obvious solution to this is to set thread priorities, with A getting the highest thread priority and C getting the lowest.
The fly in the ointment, however, is that this application will usually be running without any special privileges, and most of the set-thread-priority APIs I've come across require root privilege in order to work.
Is there any way for a non-root process to accomplish this? (Note that I'm not looking to get priority over threads in other processes, just to set the relative priority between the threads in my own process)
I guess the best way to make the effects to the thread via CPU-load independent from each other would be to run them on different cores ( if this is possible of course ).
So you need to check which CPU-Cores are available ( using Linux and MacOS/X look here how to get this: cpuset ) and if there are Cores available use the pthread_setaffinity_np-call ( you can find him here ).
If this is not possible you can change the priority. As mentioned before you will not need to be root to do this as far as I know.
There are similar calls on Windows available.
The threads are launched by std::async(func).
If not, how can I do it?
The standard does not guarantee anything about on what cores/hyperthreads your threads will run. That is up to the operating system.
If you want to get platform specific (non-portable) then there are various API's to control thread affinity - like (for example) pthread_setaffinity_np on Linux.
But I'd personally advice just leaving it to the OS - it will most likely do a good job unless you have very specific needs.
In complement to Jesper's answer, the standard offers you the function std::thread::hardware_concurrency to get the number of hardware thread contexts (0 if information not available).
The way the threads are schedules is implementation dependent. You can however be sure that your code has to share the cores with dozen of OS processes/services/daemons running with their own threads.
In view of your question, as you mention std::async(func), it's worth to mention that you could force a launch policy, for example launch::async. Some implementations offer finer control, but again, the scheduling is implementation dependent.
Server creates new thread in a threadpool. This thread reads some stuff into buffer and so on and after that, some code executes. I'd want to secure myself by changing permission of thread to lower, before this code which could be unsafe (or it's behavior could be changed ... by hacking and so on...)
I am going (ha... but have nearly no knowledge) to create a kind of "sandbox" for this unsafe code in thread. (Probably for UNIX-like OS, because I have no ideas, how to do that for Windows).
Any ideas how to change threads permission? (I use Boost library). And it would be really great, if there is an ability to define boundaries of memory usage? (Something like - if thread tries use more than 1Mb of stack\heap - something is wrong - kill it).
And one more thing :) - if I use chroot inside thread, I change root dir. for the whole application?
Thanks beforehead.
There is no way to control permissions on threads of native code in either Unix or Windows -- at least not without kernel hacking. The 'ring' mechanism of the hardware (at least x86) was designed to do something like this -- you would kick the thread into a less privileged ring. However, none of the operating systems has any user-mode support for this. chroot in a thread chroots the entire process.
The only thing you can do, if you have to use native code, is to create a process, not a thread. You can then share memory with mmap, and by using read-only on the mappings you can control the sharing. However, if you have malicious code concerns, the process has to run under a different access identity.