I am writing a server application with one connection at a time, I receive a TCP request which has symbol names of function and name of shared libraray.
My server needs to load the shared library using the dlsym system call and call the function using symbol name received.
Right now loading the shared lib and executing the function I am doing in separate thread. My doubt is when thread crashed due to segmentation fault or any signals will my process gets affected ?
Which one is better whether to run in separate thread or process.
Please ask me question If my question is not clear.
A crash in a thread takes down the whole process. And you probably wouldn't want it any other way since a crash signal (like SIGSEGV, SIGBUS, SIGABRT) means that you lost control over the behavior of the process and anything could have happened to its memory.
So if you want to isolate things, spawning separate processes is definitely better. Of course, if someone can make your process crash it's pretty close to them owning your computer anyway. I sure hope that you don't intend to expose this to untrusted users.
Related
I've been building 2 programs in C. The first program is a service that automatically shutdowns the pc if the time is past 22:00 with a countdown of 1 minutes. And at the same time it opens the second program and ask for username and password via ShellExecution in winapi. If the login is successful in the second program then the shutdown is totaly canceled. Then when the second program is closed or terminated then the shutdown process repeats all over again if the time is still past 22:00. My problem is how should I allow or make this kind of communication to happen between the two program. I'm thinking of using shared memory or pipe. I'm not sure what kind of ipc is suitable for this kind of situation. Note that if the second program is already open and logged in the shutdown process would not occure. And it should have no problem even if multiple instances of the second program is open and logged in.
I don't know if you need another process. I'd be tempted to do the login/password with another thread. That gives you shared memory with little effort.
Not being a crack Windows programmer, I don't know if you can do the ShellExecution in another thread, or if protections will get in your way.
If it didn't work and you had to do another process, I'd try a UNIX style pipe but those don't exist on Windoes, you get to a named pipes. Pipe are usually better than shared memory for security and complexity reasons. A trick is to make sure that only the correct program is on the other end of the pipe. That may or may not matter depending on how clever you expect an attacker to be.
I am trying several projects in editing a Linux kernel.
One of the projects is to write a system call function that will receive a name of a program and not allow that program to be run through execv (note, several programs can be blocked - we need a list of blocked programs).
I have figured out what to do for most of the exercise. For example, one challenge is to log all attempts of a certain process to execute any of the blocked programs - I decided to store this in the heap of the process using kmalloc().
However, I am debating where to store the "list of blocked programs" - no matter which process is running, when in execv we must have access to this list. Would it make sense then to store this list inside the heap of the init process or is there some "general" memory location that is shared between all processes (never heard of one before but I was wondering if there might be one).
If the answer is indeed inside the heap of init, how do I allocate memory there from whichever process is currently running?
I'm debugging an issue in a patch to PostgreSQL where a word in shared memory seems to get overwritten unintentionally.
Valgrind isn't any help as it can't keep track of interactions in shared memory between multiple processes.
The address that gets overwritten is fairly stable but not totally fixed, though it's always identified by a pointer in a global struct initialized early in startup by each process.
I'm trying to find a way to get a stack trace whenever any process writes to the address of interest, but it's proving rather harder than I would've expected.
gdb watchpoints aren't any help, as gdb can't follow fork() and establish the same watch on child processes. Manually doing it with multiple gdb processes is very cumbersome due to the number of child processes PostgreSQL uses and the timing issues involved in setting it up by hand.
perf userspace probes looked promising, but seem to attach only to functions, there's no apparent way to trap a write to a memory address.
So is there any way to grab stack traces for each writer to a given shared memory address across multiple processes?
gdb can't follow fork() and establish the same watch on child processes
A sufficiently recent GDB can do that. Documentation here and here.
I Would like to capture the process entry, exit and maintain a log for the entire system (probably a daemon process).
One approach was to read /proc file system periodically and maintain the list, as I do not see the possibility to register inotify for /proc. Also, for desktop applications, I could get the help of dbus, and whenever client registers to desktop, I can capture.
But for non-desktop applications, I don't know how to go ahead apart from reading /proc periodically.
Kindly provide suggestions.
You mentioned /proc, so I'm going to assume you've got a linux system there.
Install the acct package. The lastcomm command shows all processes executed and their run duration, which is what you're asking for. Have your program "tail" /var/log/account/pacct (you'll find its structure described in acct(5)) and voila. It's just notification on termination, though. To detect start-ups, you'll need to dig through the system process table periodically, if that's what you really need.
Maybe the safer way to move is to create a SuperProcess that acts as a parent and forks children. Everytime a child process stops the father can find it. That is just a thought in case that architecture fits your needs.
Of course, if the parent process is not doable then you must go to the kernel.
If you want to log really all process entry and exits, you'll need to hook into kernel. Which means modifying the kernel or at least writing a kernel module. The "linux security modules" will certainly allow hooking into entry, but I am not sure whether it's possible to hook into exit.
If you can live with occasional exit slipping past (if the binary is linked statically or somehow avoids your environment setting), there is a simple option by preloading a library.
Linux dynamic linker has a feature, that if environment variable LD_PRELOAD (see this question) names a shared library, it will force-load that library into the starting process. So you can create a library, that will in it's static initialization tell the daemon that a process has started and do it so that the process will find out when the process exits.
Static initialization is easiest done by creating a global object with constructor in C++. The dynamic linker will ensure the static constructor will run when the library is loaded.
It will also try to make the corresponding destructor to run when the process exits, so you could simply log the process in the constructor and destructor. But it won't work if the process dies of signal 9 (KILL) and I am not sure what other signals will do.
So instead you should have a daemon and in the constructor tell the daemon about process start and make sure it will notice when the process exits on it's own. One option that comes to mind is opening a unix-domain socket to the daemon and leave it open. Kernel will close it when the process dies and the daemon will notice. You should take some precautions to use high descriptor number for the socket, since some processes may assume the low descriptor numbers (3, 4, 5) are free and dup2 to them. And don't forget to allow more filedescriptors for the daemon and for the system in general.
Note that just polling the /proc filesystem you would probably miss the great number of processes that only live for split second. There are really many of them on unix.
Here is an outline of the solution that we came up with.
We created a program that read a configuration file of all possible applications that the system is able to monitor. This program read the configuration file and through a command line interface you was able to start or stop programs. The program itself stored a table in shared memory that marked applications as running or not. A interface that anybody could access could get the status of these programs. This program also had an alarm system that could either email/page or set off an alarm.
This solution does not require any changes to the kernel and is therefore a less painful solution.
Hope this helps.
I am attempting to have a bunch of independent programs intelligently allocate shared resources among themselves. However, I could have only one program running, or could have a whole bunch of them.
My thought was to mmap a virtual file in each program, but the concurrency is killing me. Mutexes are obviously ineffective because each program could have a lock on the file and be completely oblivious of the others. However, my attempts to write a semaphore have all failed, since the semaphore would be internal to the file, and I can't rely on only one thing writing to it at a time, etc.
I've seen quite a bit about named pipes but it doesn't seem to be to be a practical solution for what I'm doing since I don't know how many other programs there will be, if any, nor any way of identifying which program is participating in my resource-sharing operation.
You could use a UNIX-domain socket (AF_UNIX) - see man 7 unix.
When a process starts up, it tries to bind() a well-known path. If the bind() succeeds then it knows that it is the first to start up, and becomes the "resource allocator". If the bind() fails with EADDRINUSE then another process is already running, and it can connect() to it instead.
You could also use a dedicated resource allocator process that always listens on the path, and arbitrates resource requests.
Not entirely clear what you're trying to do, but personally my first thought would be to use dbus (more detail). Should be easy enough within that framework for your processes/programs to register/announce themselves and enumerate/signal other registered processes, and/or to create a central resource arbiter and communicate with it. Readily available on any system with gnome or KDE installed too.