Comments on: Linux Resource Controls

By: sudheendra

sudheendra — Mon, 19 May 2008 12:08:11 +0000

“50 processes with 5M of memory each is more than enough to cause a machine with 128M of RAM to swap to death”

Could you please let me how you were able to set per process memory usage. In limits.conf, I see “memlock - max locked-in-memory address space (KB)” and “rss - max resident set size (KB)”, which one do i need to set… and what is the difference and significance between these two …

Scenario: I have a 4GB ram RHEL login server, here I want to put a restriction like — any user process should not take more than 512MB of RAM….

is it possible this way?

Thanks,
Sudheendra

By: etbe

etbe — Sat, 09 Feb 2008 22:24:03 +0000

Olaf: I agree that it would be good to have such access controls as you describe and that it would be good to make it extremely difficult to break things for others.

But such goals conflict with other goals (such as making things fast), and we miss out on such features.

I agree that the defaults should be optimised for the majority of cases in most situations, except where the majority case will be dangerous for the minority. The Debian default of creating mode 755 home directories is a bad idea IMHO.

By: Olaf van der Spek

Olaf van der Spek — Sat, 09 Feb 2008 10:04:46 +0000

> Olaf: Trust is a relative thing. In university environments it was always common to have systems configured such that one user could break things for others. An occasional breakage was a learning experience, breakage attributed to malice could be punished.

But what is the reason for that? Is it so nice that users can break stuff for others or does the system simply provide inadequate controls to prevent it (easily)?

> Social pressure from other students did a reasonable job of policing the system.

Depending on social pressure for security is not desirable if it can be avoided.

> As for world-readable home directories, that is only suitable for certain small projects. If you have a machine purchased for a small group of people to use with a single project then it makes some sense. In all other cases (the vast majority of cases) it’s a bad idea.

Shouldn’t the defaults be optimized for the majority of cases?

By: etbe

etbe — Sat, 09 Feb 2008 01:06:43 +0000

Olaf: Trust is a relative thing. In university environments it was always common to have systems configured such that one user could break things for others. An occasional breakage was a learning experience, breakage attributed to malice could be punished.

I recall one occasion at university when I accidentally DOSed an important time-sharing system (a bug in my code combined with a bug in the ulimit controls which were apparently applied per session not per UID). As soon as I realised my mistake (minutes before other students realised) I packed up my stuff, ran to the station, and took the first train home. Social pressure from other students did a reasonable job of policing the system.

Virtual systems do help. But the total lack of IO bandwidth controls still allows the potential for DOS attacks unless you have separate spindles.

As for world-readable home directories, that is only suitable for certain small projects. If you have a machine purchased for a small group of people to use with a single project then it makes some sense. In all other cases (the vast majority of cases) it’s a bad idea.

By: Olaf van der Spek

Olaf van der Spek — Fri, 08 Feb 2008 10:31:53 +0000

It’s like Linux is not suitable for systems where users can’t be trusted. I guess this is one of the reasons why virtual systems are so popular, because they do provide this kind of controls/limits.

An OT question: what’s your opinion on world-readable home dirs?

By: etbe

etbe — Fri, 08 Feb 2008 01:11:01 +0000

Olaf: These basic resources simply can’t be limited on a per-user basis with a stock Linux kernel. There have been experimental patches to allow overall controls of per-user memory and RAM use (which have never come close to being accepted in kernel.org AFAIK) and it is possible to limit overall network use per user with iptables and cron jobs (but it’s painful to do and not the problem I face).

If I could set a per-user limit I would. Of course I still face the issue of root:user_r not being equivalent to root:system_r or root:sysadm_r.

By: Olaf van der Spek

Olaf van der Spek — Thu, 07 Feb 2008 13:09:38 +0000

> A more practical limit is five processes for a single shell session (one or two background jobs, a foreground job where one process pipes data to another, and the shell).

Why is a process limit needed at all?
Can’t you just limit the basic resources (CPU time, RAM, storage and network)?

> For running the occasional memory intensive process such as GCC the per-process memory limit needs to be at least 20M, if the user was to compile big C++ programs then 100M may be needed (I’ve seen a G++ process use more than 90M of memory when compiling a KDE source file). This means that a single user who can launch 20 processes which can each use 20M of memory could use 400M of memory,

Why can’t you just set a per-user limit instead of a per-process limit?