Crond

From Wiki

(Difference between revisions)
Jump to: navigation, search
(Configuration)
Line 3: Line 3:
= What our modifications add? =
= What our modifications add? =
== Chroot ==
== Chroot ==
-
The normal crond adds decent security by running all scripts with user privileges but this doesn't protect world writable directories and files. Also world readable files are open to all users, so you can't protect your user's data from leaking to other users on the machine.
+
The normal crond adds decent security by running all scripts with user privileges but this doesn't protect world writable directories and files. Also, world readable files are open to all users, so you can't protect one user's data from leaking to other users on the machine.
We worked to solve these issues and add a separation between users.  
We worked to solve these issues and add a separation between users.  
-
So what we did was to add '''chroot''' support to our crond. What this means is that a user can see only his own files and the programs from the BaseOS. The user is insulated from everyone else on the machine.  
+
So what we did was to add '''chroot''' support to our crond. What this means is that a user can see only its own files and the programs from the BaseOS. The user is insulated from everyone else on the machine.  
More about the chroot structure and mechanism can be found [[Chrooting|here]].   
More about the chroot structure and mechanism can be found [[Chrooting|here]].   
== Limits ==
== Limits ==
-
Every time a user runs a script on the server it's script can use as much resources as it's parent process can, this is simply how processes work on Linux. But Linux gives us a way of controlling the resource allocation of each process, the parent process only have to set a new limit before starting the new process. So after successful implementation of those limits in SuExec We decided to implement them in crond also.
+
Every time a user runs a script on the server, its script can use as much resources as its parent process can, this is simply how processes work on Linux. But Linux gives us a way of controlling the resource allocation of each process, the parent process only has to set a new limit before starting the new process. So, after the successful implementation of those limits in SuExec, we decided to implement them in crond as well.
We have currently implemented the following resource limits:
We have currently implemented the following resource limits:
Line 20: Line 20:
* Maximum number of files that a process may open (RLIMIT_NOFILE)
* Maximum number of files that a process may open (RLIMIT_NOFILE)
* Maximum number of processes that a user may have in any single time on the system (RLIMIT_NPROC)
* Maximum number of processes that a user may have in any single time on the system (RLIMIT_NPROC)
-
If you want more information about these limits please refer the the getrlimit man page on your Linux machine:
+
If you want more information about these limits please refer to the getrlimit man page on your Linux machine:
  man getrlimit
  man getrlimit
Line 29: Line 29:
= Configuration =
= Configuration =
-
Our crond offers configuration for the limits it imposes for every processes. You can either change the global values or on a per user basis.
+
Our crond offers configuration for the limits it imposes for every process. You can either change the global values or on a per-user basis.
The configuration file is '''/usr/local/apache/conf/rlimit-config''' and it is used by both SuExec and crond.
The configuration file is '''/usr/local/apache/conf/rlimit-config''' and it is used by both SuExec and crond.
-
It's syntax is very simple:
+
Its syntax is very simple:
  username:memlimit:cpulimit:numproc:filesize:ofiles
  username:memlimit:cpulimit:numproc:filesize:ofiles
  username - the username for which these limits will apply
  username - the username for which these limits will apply
Line 41: Line 41:
  filesize - RLIMIT_FSIZE
  filesize - RLIMIT_FSIZE
  ofiles  - RLIMIT_NOFILE
  ofiles  - RLIMIT_NOFILE
-
Here is an example custom limits for user '''joyme''':
+
Here is an exemplary custom limits entry for user '''joyme''':
  joyme:50000000:120:20:200000000:40
  joyme:50000000:120:20:200000000:40
So processes of user '''joyme''' will have the following limitations:
So processes of user '''joyme''' will have the following limitations:
# Maximum '''50MB''' of memory
# Maximum '''50MB''' of memory
-
# Maximum of '''120''' CPU ticks (do not mistake this with actual second, it is not)
+
# Maximum of '''120''' CPU ticks (do not mistake a CPU tick with an actual second, it is not)
# Maximum of '''20''' simultaneous processes at any given time
# Maximum of '''20''' simultaneous processes at any given time
# The biggest file it can create or read will be '''200MB'''  
# The biggest file it can create or read will be '''200MB'''  
# The maximum number of files it can open simultaneously will be '''40'''
# The maximum number of files it can open simultaneously will be '''40'''
-
If a username is not found in the rlimit-config the Default limits are applied to its processes.  
+
If a username is not found in the rlimit-config, the Default limits are applied to its processes.  
You can change the default limits by using a magic username in the rlimit-config. If you have a line with username '''00''' in the configuration file, those limits will be used instead of the default if a username is not found in the file.
You can change the default limits by using a magic username in the rlimit-config. If you have a line with username '''00''' in the configuration file, those limits will be used instead of the default if a username is not found in the file.

Revision as of 13:40, 13 September 2010


Contents

What our modifications add?

Chroot

The normal crond adds decent security by running all scripts with user privileges but this doesn't protect world writable directories and files. Also, world readable files are open to all users, so you can't protect one user's data from leaking to other users on the machine.

We worked to solve these issues and add a separation between users.

So what we did was to add chroot support to our crond. What this means is that a user can see only its own files and the programs from the BaseOS. The user is insulated from everyone else on the machine.

More about the chroot structure and mechanism can be found here.

Limits

Every time a user runs a script on the server, its script can use as much resources as its parent process can, this is simply how processes work on Linux. But Linux gives us a way of controlling the resource allocation of each process, the parent process only has to set a new limit before starting the new process. So, after the successful implementation of those limits in SuExec, we decided to implement them in crond as well.

We have currently implemented the following resource limits:

If you want more information about these limits please refer to the getrlimit man page on your Linux machine:

man getrlimit

Statistics

In Linux it is possible to collect resource statistics from each child process. We decided to use this functionality to collect CPU usage statistics from all processes started by crond.

So now before every execution crond logs the it, but after that, it logs the resources used by the process. This way we have information about every process executed by crond and we simply have to read the logs and calculate the statistics.

Configuration

Our crond offers configuration for the limits it imposes for every process. You can either change the global values or on a per-user basis.

The configuration file is /usr/local/apache/conf/rlimit-config and it is used by both SuExec and crond.

Its syntax is very simple:

username:memlimit:cpulimit:numproc:filesize:ofiles
username - the username for which these limits will apply
memlimit - RLIMIT_AS
cpulimit - RLIMIT_CPU
numporoc - RLIMIT_NPROC
filesize - RLIMIT_FSIZE
ofiles   - RLIMIT_NOFILE

Here is an exemplary custom limits entry for user joyme:

joyme:50000000:120:20:200000000:40

So processes of user joyme will have the following limitations:

  1. Maximum 50MB of memory
  2. Maximum of 120 CPU ticks (do not mistake a CPU tick with an actual second, it is not)
  3. Maximum of 20 simultaneous processes at any given time
  4. The biggest file it can create or read will be 200MB
  5. The maximum number of files it can open simultaneously will be 40

If a username is not found in the rlimit-config, the Default limits are applied to its processes.

You can change the default limits by using a magic username in the rlimit-config. If you have a line with username 00 in the configuration file, those limits will be used instead of the default if a username is not found in the file.

Retrieved from "http://docs.1h.com/Crond"
Personal tools
Namespaces
Variants
Actions
Navigation
Toolbox