0

hi i tried to allocate memory continuously using calloc function . so obviously the system memory gets filled and crashed. But the worst part is even if i am a standard user and if i am able to run that program the system is crashing . how can we block this to happen for standard user.

code used is :

#include <stdio.h>
#include <stdlib.h>

int main()
{
  while(1)
  {
    int *abc;
    abc=(int*)calloc(1000,sizeof(int));
   }
}

There might be some way to block this , or else user gets ssh access then easily he can crash the system easily .

Grijesh Chauhan
  • 57,103
  • 20
  • 141
  • 208
Naggappan Ramukannan
  • 2,564
  • 9
  • 36
  • 59
  • don't cast calloc() returned address here in C, also you forget to free memory. – Grijesh Chauhan Jul 18 '13 at 18:12
  • You're allocating memory forever. I'd expect it to crash? – John Jul 18 '13 at 18:13
  • 1
    Check these links http://unix.stackexchange.com/questions/34334/how-to-create-a-user-with-limited-ram-usage and http://stackoverflow.com/questions/437433/limit-in-the-memory-and-cpu-available-for-a-user-in-linux – VoidPointer Jul 18 '13 at 18:14
  • You can test your program with valgrind for memory leaks further put a condition like this void *v = malloc(amt); if(!v){ printf("out of memory"); exit(EXIT_FAILURE); – Sanyam Goel Jul 18 '13 at 18:16
  • I really don't understand the question, what is a 'standard user' in your context and what other kind of users are there? Obviously an infinite memory allocation is going to crash, why would you even want that in the first place for non-standard users? – Lochemage Jul 18 '13 at 18:16
  • @John, Naggappan RM: A good read [Modern Memory Management](http://www.onlamp.com/pub/a/onlamp/2005/10/27/memory-management.html?page=1) – Grijesh Chauhan Jul 18 '13 at 18:17
  • 1
    @GrijeshChauhan Thanks for the link. At first glance I'd be wary of a "modern memory management" article published in 2005, but I'll take a look. :) – John Jul 18 '13 at 18:20
  • 1
    @John actually there is one more new, I am searching. If I find, will share that here – Grijesh Chauhan Jul 18 '13 at 18:23
  • I think most of you misunderstood OP's intention. I think he's trying to say that if he has a system where it allows other users to execute their binaries, how could one prevent these users from executing something like the code snippet without crashing/slowing down the entire OS. – cheeyos Jul 18 '13 at 18:24
  • A single misbehaving program should not bring down the whole OS. How does ssh access factor into your question?? – abelenky Jul 18 '13 at 18:25
  • 5
    This is not really a code question, it is more a question on linux/unix administration. Perhaps more appropriate as a question in http://unix.stackexchange.com? – Tevo D Jul 18 '13 at 18:33
  • there is no way that this program should crash linux. Might slow tings down a bit, but even thats unlikely – pm100 Jul 18 '13 at 18:57
  • @pm100: On a system with virtual memory partitions mounted, it can easily use disk thrashing to slow everything down so much that the entire computer is effectively worthless. – Ben Voigt Jul 19 '13 at 14:39

5 Answers5

3

You can set up various memory limits.

ulimit springs to mind. This can be set by the shell (see http://unixhelp.ed.ac.uk/CGI/man-cgi?ulimit). There is also a way of setting them system wide. There is a file that stores these but off the top of my head cannot remember where it is located. You need to google it.

Ed Heal
  • 59,252
  • 17
  • 87
  • 127
1

You should then set up memory limit for your ssh shells. There is some discussion here

nio
  • 5,141
  • 2
  • 24
  • 35
0

First, you are allocating memory without freeing any. The system's memory is finite, which means that at some point, you'll run out of memory, if the OS doesn't crash your system first.
That's the first thing to fix. As for preventing a standard user from allocating memory, a program cannot automatically identify if a user is standard or not.
So, you might need to define a variable/constant to which the system passes an argument to the program when it is ran. Check the constant/variable to determine if the user is standard. If the user isn't, that snippet is not run.
How to identify standard and privileged users differ from OS to OS; so, you might need to figure that out first.

Hope this gives you somewhere to start.

Kneel-Before-ZOD
  • 4,141
  • 1
  • 24
  • 26
  • 2
    I think you missed the point. The point is that yes, this program crashes the system, which is by design. The concern is that any general user (not root) may crash the system with bad code. – Tevo D Jul 18 '13 at 18:31
  • Okay; if the crash is by design, ignore the first part. But since a program doesn't know who a standard user is, an input must be passed to it from the system to differentiate between users. – Kneel-Before-ZOD Jul 18 '13 at 18:34
0

in unix lands there is a concept of 'nice' which controls scheduling priority... so as a process is becoming more of a jerk it will get a lower and lower nice number... and the pre-emptive scheduler will give it less and less time... other VM mechanisms could kill it... but it is up to the kernel/scheduler to keep the process from becoming too resource intensive....

In practicality, every system that I have worked on could be affected with the type of code you have written.

Grady Player
  • 14,399
  • 2
  • 48
  • 76
0

I'm not sure if you are looking at this from the right angle.

Given a user has shell access to your system, and that user has malicious intent, then a simple DoS (denial of service) Attack that crashes your system is the least of your worries.

That being said, unix environments usually avoid this problem by restricting shell access to trusted users, and only in very rare cases it is necessary to directly restrict memory consumption for processes.

Andreas Grapentin
  • 5,499
  • 4
  • 39
  • 57