The application which can be run by different users (Admin, Non-Admin) on Windows at once. It has a critical section which cannot be executed at the same time by different (or the same) user.
To prevent that I'm using Global Mutex from WinApi by calling:
CreateMutex(NULL, true, "Global\\MyMutex"); and then after job is done Mutex is released. "Global" prefix is added to make Mutex visible between all Windows sessions. (It's optional but I want to present that this Mutex is not Local one).
And now the problem:
Assume there is an attacker which want to prevent critical section to be executed by anyone, so she create a program which create a mutex with name "Global\\MyMutex" and never release it... In that way she was able to perform DoS attack on my application for other users - as they are not able to reach critical section.
The question is - How can I prevent such attack scenario with Global Mutex?
First, doing it with a global mutex requires admin. Second, you can do it with a plain named mutex, in which yes, a malicious app can prevent your app from running. But a malicious app running in your system may do far more problematic things than just blocking your application.
Solutions:
Create a named mutex based on some weird unique string (say a CLSID) so a malicious app won't detect it easily.
Do not lock per-application. You may issue a warning on a mutex found locked for a long time, but still let the user proceed. It depends on what your application is designed to do. In my opinion this is the better approach.
Do not bother. If one malicious-app creator does bother in attacking your application, you would have been long successful anyway.
You can:
Not use a global mutex.
That's basically it.
But you say, "How can I stop my application doing something twice at the same time?"
Well, what would happen if the attacker did that thing over and over? It would screw up your application because nobody else would be able to do it at the same time, right? Mutex or no mutex.
So you need to figure out how to make it so it can be done at the same time.
Your other option is to declare that you don't really care about security. Sometimes that's an option, like if you trust everyone who logs into the computer. It doesn't look good if someone does decide to attack your application.
Related
I've created a DLL that injects into a piece of software, the purpose of this DLL is to encrypt some data during run time that shouldn't be accessible by others.
Anyways, we've run into an issue where the encryption/decryption process messes up because another thread (I'm assuming) access' this process for it's own encryption/decryption (in the wrong order).
I don't have access to the software's native code.
My question is....
If I were to make an std::mutex to preform locking operations within a class that is created inside of the injected DLL, but called from the original softwares threads... Would these threads abide by the locking scheme of the DLL? I think the answer is yes, I just want to be sure...
If I were to make an std::mutex to preform locking operations within a class that is created inside of the injected DLL, but called from the original softwares threads...
No, because the other thread in the older code won't know about the mutex, much less abide to it. (mutexes don't magically lock the resource, they are just a way for two or many pieces of code to "signal" each other that some of their "group" needs exclusive access to a resource. If any of the pieces of code ignores the discipline, a mutex isn't going to stop it)
I want to switch from CreatMutex to boost::interprocess::named_mutex to limit my application to a single instance. Both methods works when the application runs and ends just fine. However, the lock is not released when the application crashes and using boost::interprocess::named_mutex. I could resolve that issue by using two name_mutex but I don't really understand the issue.
Why is the lock for boost::interprocess::named_mutex not released when the application crashes but it is release with CreatMutex? What's the difference?
boost::interprocess::named_mutex mutex(boost::interprocess::open_or_create, "my_mutex");
boost::interprocess::scoped_lock<boost::interprocess::named_mutex> lock(mutex, boost::interprocess::try_to_lock);
if(!lock) {
return 1; //exit
}
//application may crash here.
boost::interprocess::named_mutex::remove("my_mutex");
return 1; //exit
Caveat: I've not spent much time with boost::interprocess, so this information is just from a quick inspection of the source. That said, I've used the Windows synchronisation API's a lot, so here goes...
The main difference between the two methods of interprocess synchronisation is how the object exists within the system.
With boost::interprocess::named_mutex, as well as a system-specific mutex, it looks like a synchronisation object is created as a file on the system. The location of the file is based on Registry entries (see note 1) (at least in Boost 1.54.0)... it's most likely located under the Common Application Data folder (see note 2). When the aplication crashes, this file is, in your case, not removed. I'm not sure if this is by design... however in the case of an application crash, it's perhaps best not to mess with the file system, just in case.
Conversely, when you use CreateMutex, an object is created at the kernel mode, which for named mutexes can be accessed by several applications. You get a handle to the Mutex by specifying the name when you create it, and you lose the handle when you call CloseHandle on it. The mutex object is destroyed when there are no more handles referencing it.
The important part of this is in the documentation:
The system closes the handle automatically when the process terminates. The mutex object is destroyed when its last handle has been closed.
This basically means that Windows will clean up after your application.
Note that if you don't perform a ReleaseMutex, and your application owns the mutex when it dies, then it's possible/likely that a waiting thread or process would see that the mutex had been abandoned (WaitForSingleObject returns WAIT_ABANDONED), and would gain ownership.
I apologise for not providing a solution, but I hope it answers your question about why the two systems act differently.
Just as an aside, using registry entries to get this information is horrible - it would be safer, and more future-proof, to use SHGetKnownFolderPath. But I digress.
Depending on your OS version, this could be %ALLUSERSPROFILE%\Application Data\boost.interprocess or ProgramData\boost.interprocess, or somewhere else entirely.
What you want is not trivial and the interprocess_mutex definitively the wrong way to do.
What you may could do is remove the mutex on termination, by providing a remover destructor and/or in a catch(...). But this is not guaranteed to work, since it won't be done if you terminate the process directly (from the OS). Also it could accidently remove the mutex while your application starts twice.
One approach is to safe the process-id (for example in a shared memory) on the first time your program starts and remove it when it stops. Everytime you start the application read and check if the id still in process, if not, start the program.
Usually developing applications I am used to print to console in order to get useful debugging/tracing information. The application I am working now since it is multi-threaded sometimes I see my printf overlapping each other.
I tried to synchronize the screen using a mutex but I end up in slowing and blocking the app. How to solve this issue?
I am aware of MT logging libraries but in using them, since I log too much, I slow ( a bit ) my app.
I was thinking to the following idea..instead of logging within my applications why not log outside it? I would like to send logging information via socket to a second application process that actually print out on the screen.
Are you aware of any library already doing this?
I use Linux/gcc.
thanks
afg
You have 3 options. In increasing order of complexity:
Just use a simple mutex within each thread. The mutex is shared by all threads.
Send all the output to a single thread that does nothing but the logging.
Send all the output to a separate logging application.
Under most circumstances, I would go with #2. #1 is fine as a starting point, but in all but the most trivial applications you can run in to problems serializing the application. #2 is still very simple, and simple is a good thing, but it is also quite scalable. You still end up doing the processing in the main application, but for the vast majority of applications you gain nothing by spinning this off to it's own, dedicated application.
Number 3 is what you're going to do in preformance-critical server type applications, but the minimal performance gain you get with this approach is 1: very difficult to achieve, 2: very easy to screw up, and 3: not the only or even most compelling reason people generally take this approach. Rather, people typically take this approach when they need the logging service to be seperated from the applications using it.
Which OS are you using?
Not sure about specific library's, but one of the classical approaches to this sort of problem is to use a logging queue, which is worked by a writer thread, who's job is purely to write the log file.
You need to be aware, either with a threaded approach, or a multi-process approach that the write queue may back up, meaning it needs to be managed, either by discarding entries or by slowing down your application (which is obviously easier if it's the threaded approach).
It's also common to have some way of categorising your logging output, so that you can have one section of your code logging at a high level, whilst another section of your code logs at a much lower level. This makes it much easier to manage the amount of output that's being written to files and offers you the option of releasing the code with the logging in it, but turned off so that it can be used for fault diagnosis when installed.
As I know critical section has less weight.
Critical section
Using critical section
If you use gcc, you could use atomic accesses. Link.
Frankly, a Mutex is the only way you really want to do that, so it's always going to be slow in your case because you're using so many print statements.... so to solve your question then, don't use so many print_f statements; that's your problem to begin with.
Okay, is your solution using a mutex to print? Perhaps you should have a mutex to a message queue which another thread is processing to print; that has a potential hang up, but I think will be faster. So, use an active logging thread that spins waiting for incoming messages to print. The networking solution could work too, but that requires more work; try this first.
What you can do is to have one queue per thread, and have the logging thread routinely go through each of these and post the message somewhere.
This is fairly easy to set up and the amount of contention can be very low (just a pointer swap or two, which can be done w/o locking anything).
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.
I have used a version of double checked locking in my CF app (before I knew what double checked locking was).
Essentially, I check for the existance of an object. If it is not present, I lock (usually using a named lock) and before I try and create the object I check for existance again. I thought this was a neat way to stop multiple objects being created and stop excessive locking in the system.
This seems to work, in that there is not excessive locking and object duplicates don't get created. However, I have recently learned that Double Checked Locking dosn't work in Java, what I don't know is if this holds true in CF, seeing as CF threads and locks are not quite the same as native Java threads and locks.
To add on to what Ben Doom said about Java, this is fairly standard practice in ColdFusion, specifically with an application initialization routine where you set up your application variables.
Without having at least one lock, you are letting the initial hits to your web application all initialize the application variables at the same time. This assumes that your application is busy enough to warrant this. The danger is only there if your application is busy at the time your application is first starting up.
The first lock makes sure only one request at a time initializes your variables.
The second lock, embedded within the first, will check to make sure a variable defined at the end of your initialization code exists, such as application.started. If it exists, the user is kicked out.
The double-locking pattern has saved my skin on busy sites, however, with VERY busy sites, the queue of requests for the application's initial hit to complete can climb too high, too quickly, and cause the server to crash. The idea is, the requests are waiting for the first hit, which is slow, then the second one breaks into the first cflock, and is quickly rejected. With hundreds or thousands of requests in the queue, growing every millisecond, they are all funneling down to the first cflock block. The solution is to set a very low timeout on the first cflock and not throw (or catch and duck) the lock timeout error.
As a final note, this behavior that I described has been deprecated with ColdFusion 7's onApplicationStart() method of your Application.cfc. If you are using onApplicationStart(), then you shouldn't be locking at all for your application init routine. Application.cfc is well locked already.
To conclude, yes, double-checked locking works in ColdFusion. It's helpful in a few certain circumstances, but do it right. I don't know the schematics of why it works as opposed to Java's threading model, chances are it's manually checking some sort of lookup table in the background of your ColdFusion server.
Java is threadsafe, so it isn't so much that your locks won't work as that they aren't necessary. Basically, in CF 6+, locks are needed for preventing race conditions or creating/althering objects that exist outside Java's control (files, for example).
To open a whole other can of worms...
Why don't you use a Dependency Injection library, such as ColdSpring, to keep track of your objects and prevent circular dependencies.