diff --git a/en_US.ISO8859-1/books/handbook/users/chapter.sgml b/en_US.ISO8859-1/books/handbook/users/chapter.sgml index 880375942a..b91dbf7464 100644 --- a/en_US.ISO8859-1/books/handbook/users/chapter.sgml +++ b/en_US.ISO8859-1/books/handbook/users/chapter.sgml @@ -1,425 +1,634 @@ Users and Basic Account Management Synopsis Contributed by &a.nbm; February 2000. All access to the system is achieved via accounts, and all processes are run by users, so user and account management are of integral importance on FreeBSD systems. There are three main types of accounts; the Superuser, system users, and user accounts. The Superuser account, usually called root, is used to manage the system with no limitations on privileges. System users run services. Finally, user accounts are used by real people, who log on, read mail, and so forth. The Superuser Account The superuser account, usually called root, comes preconfigured, and facilitates system administration, and should not be used for day-to-day tasks like sending and receiving mail, general exploration of the system, or programming. This is because the superuser, unlike normal user accounts, can operate without limits, and misuse of the superuser account may result in spectacular disasters. User accounts are unable to destroy the system by mistake, so it is generally best to use normal user accounts whenever possible, unless you especially need the extra privilege. In addition, always double and triple-check commands you issue as the superuser, since an extra space or missing character can mean irreparable data loss. Those extra privileges you needed when you decided to change to the superuser mean that the safeguards of your normal user account no longer apply. So, the first thing you should do after reading this chapter, is to create an unprivileged user account for yourself for general usage, if you haven't already. This applies equally whether you're running a multi-user or single-user machine. Later in this chapter, we discuss how to create additional accounts, and how to change between the normal user and superuser. System Accounts System users are those used to run services such as DNS, mail, web servers, and so forth. The reason for this is security; if all services ran as the superuser, they could act without restriction. Examples of system users are daemon, operator, bind (for the Domain Name Service), and news. Often sysadmins create httpd to run web servers they install. nobody is the generic unprivileged system user, but the more services that use nobody, the more privileged it becomes. User Accounts User accounts are the primary means of access for real people to the system, and these accounts insulate the user and the environment, preventing the users from damaging the system or other users, and allowing users to customize their environment without affecting others. Every person accessing your system should have their own unique user account. This allows you to find out who is doing what, and prevent people from clobbering each others' settings, and reading mail meant for the other, and so forth. Each user can set up their own environment to accommodate their use of the system, by using alternate shells, editors, key bindings, and language. Modifying Accounts pw is a powerful and flexible means to modify accounts, but adduser is recommended for creating new accounts, and rmuser for deleting accounts. chpass allows both the system administrator and normal users to adjust passwords, shells, and personal information. passwd is the more common means to change passwords specifically, however. adduser adduser is a simple program for adding new users. It creates passwd and group entries for the user, as well as creating their home directory, copy in some default dotfiles from /usr/share/skel, and can optionally mail the user a welcome message. To create the initial configuration file, use adduser -s -config_create. The makes adduser default to quiet. We use later when we want to change defaults. Next, we configure adduser defaults, and create our first user account, since using root for normal usage is evil and nasty. Changing the configuration for adduser &prompt.root; adduser -v Use option ``-silent'' if you don't want to see all warnings and questions. Check /etc/shells Check /etc/master.passwd Check /etc/group Enter your default shell: csh date no sh tcsh [sh]: tcsh Your default shell is: tcsh -> /usr/local/bin/tcsh Enter your default HOME partition: [/home]: Copy dotfiles from: /usr/share/skel no [/usr/share/skel]: Send message from file: /etc/adduser.message no [/etc/adduser.message]: no Do not send message Use passwords (y/n) [y]: y Write your changes to /etc/adduser.conf? (y/n) [n]: y Ok, let's go. Don't worry about mistakes. I will give you the chance later to correct any input. Enter username [a-z0-9_-]: jru Enter full name []: J. Random User Enter shell csh date no sh tcsh [tcsh]: Enter home directory (full path) [/home/jru]: Uid [1001]: Enter login class: default []: Login group jru [jru]: Login group is ``jru''. Invite jru into other groups: guest no [no]: wheel Enter password []: Enter password again []: Name: jru Password: **** Fullname: J. Random User Uid: 1007 Gid: 1007 (jru) Class: Groups: jru wheel HOME: /home/jru Shell: /usr/local/bin/tcsh OK? (y/n) [y]: y Added user ``jru'' Copy files from /usr/share/skel to /home/jru Add another user? (y/n) [y]: n Goodbye! &prompt.root; In summary, we changed the default shell to tcsh (an additional shell found in packages), and turned off the sending of a welcome mail to added users. We then saved the configuration, and then created an account for jru, and we made sure jru is in wheel group (which we'll see is important later). The password you type in isn't echoed, nor are asterisks displayed. Make sure you don't mistype the password twice :-) Just use adduser without arguments from now on, and you won't have to go through changing the defaults. If the program asks you to change the defaults, exit the program, and try the option. rmuser rmuser removes users from the system, including any traces beyond the user database. rmuser performs the following steps: Removes the user's &man.crontab.1; entry (if any). Removes any &man.at.1; jobs belonging to the user. Kills all processes owned by the user Removes the user from the system's local password file. Removes the user's home directory (if it is owned by the user) Removes the incoming mail files belonging to the user from /var/mail. Removes all files owned by the user from temporary file storage areas such as /tmp. Finally, removes the username from all groups to which it belongs in /etc/group. If a group becomes empty and the group name is the same as the username, the group is removed; this complements the per-user unique groups created by &man.adduser.8;. rmuser can't be used to remove superuser accounts, since that is almost always an indication of massive destruction. By default, an interactive mode is used, which attempts to make sure you know what you're doing. rmuser interactive account removal &prompt.root; rmuser jru Matching password entry: jru:*:1000:1000::0:0:J. Random User:/home/jru:/usr/local/bin/tcsh Is this the entry you wish to remove? y Remove user's home directory (/home/jru)? y Updating password file, updating databases, done. Updating group file: trusted (removing group jru -- personal group is empty) done. Removing user's incoming mail file /var/mail/jru: done. Removing files belonging to jru from /tmp: done. Removing files belonging to jru from /var/tmp: done. Removing files belonging to jru from /var/tmp/vi.recover: done. &prompt.root; pw pw is a command line utility to create, remove, modify, and display users and groups, and functions as an editor of the system user and group files. It is designed to be useful both as a directly executed command and for use from shell scripts. &man.pw.8; has all the information. chpass chpass changes user database information such as passwords, shells, and personal information. Only system administrators, as the superuser, may change other users' information and passwords with chpass. Passed no options, besides the optional username, chpass displays an editor containing user information, and upon exit from the editor, attempts to change the information in the user database. Interactive chpass by Superuser #Changing user database information for jru. Login: jru Password: * Uid [#]: 1000 Gid [# or name]: 1000 Change [month day year]: Expire [month day year]: Class: Home directory: /home/jru Shell: /usr/local/bin/tcsh Full Name: J. Random User Office Location: Office Phone: Home Phone: Other information: The normal user can change only a small subsection of this information, and only for themselves. Interactive chpass by Normal User #Changing user database information for jru. Shell: /usr/local/bin/tcsh Full Name: J. Random User Office Location: Office Phone: Home Phone: Other information: chfn and chsh are just links to chpass, as are ypchpass, ypchfn, and ypchsh. NIS support is automatic, so specifying the yp before the command is not necessary. passwd passwd is the usual way to change your own password as a user, or another user's password as the superuser. Users must type in their original password before changing their password, to prevent an unauthorized person from changing their password when the user is away from their console. passwd &prompt.user; passwd Changing local password for jru. Old password: New password: Retype new password: passwd: updating the database... passwd: done &prompt.root; passwd jru Changing local password for jru. New password: Retype new password: passwd: updating the database... passwd: done yppasswd is just a link to passwd. NIS support is automatic, so specifying the yp before the command is not necessary. - - Limiting and Personalizing Users + + Limiting Users + + If you run a multi-user system, chances are that you do not trust + all of your users not to damage your system. FreeBSD provides a + number of ways a system administrator can limit the amount of system + resources an individual user can use. These limits are generally + divided into two sections: disk quotas, and other resources + limits. + + Disk quotas are a way for the system administrator to tell the + filesystem the amount of disk space a user may use; moreover, they + provide a way to quickly check on the disk usage of a user without + having to calculate it every time. Quotas are discussed in . + + The other resource limits include ways to limit the amount of + CPU, memory, and other resources a user may consume. These are + defined using login classes and are discussed here. + + Login classes are defined in + /etc/login.conf. The precise semantics are + beyond the scope of this section, but are described in detail in the + &man.login.conf.5; manual page. It is sufficient to say that each + user can is assigned to a login class (default by + default), and that each login class has a set of login capabilities + associated with it. A login capability is a + name=value + pair, where name is a well-known + identifier and value is an arbitrary + string processed accordingly depending on the name. Setting up login + classes and capabilities is rather straight-forward, and is also + described in &man.login.conf.5;. + + Resource limits are different from plain vanilla login + capabilities in two ways. First, for every limit, there is a soft + (current) and hard limit. A soft limit may be adjusted by the user + or application, but may be no higher than the hard limit. The latter + may be lowered by the user, but never raised. Second, most resource + limits apply per process to a specific user, not the user as a whole. + Note, however, that these differences are mandated by the specific + handling of the limits, not by the implementation of the login + capability framework (i.e., they are not really + a special case of login capabilities). + + And so, without further ado, below are the most commonly used + resource limits (the rest, along with all the other login + capabilities, may be found in &man.login.conf.5;). + + + + coredumpsize + + + The limit on the size of a core file generated by a program + is, for obvious reasons, subordinate to other limits on disk + usage (e.g., filesize, or disk quotas). + Nevertheless, it is often used as a less-severe method of + controlling disk space consumption: since users do not generate + core files themselves, and often do not delete them, setting this + may save them from running out of disk space should a large + program (e.g., Emacs) crash. + + + + + cputime + + + This is the maximum amount of CPU time a user's process may + consume. Offending processes will be killed by the kernel. - Quotas allow the system administrator to set disk usage - maximums, and users to check their disk usage, if quotas are - used on the system. Quotas are discussed in their own chapter. + + This is a limit on CPU time + consumed, not percentage of the CPU as displayed in some + fields by &man.top.1; and &man.ps.1;. A limit on the + latter is, at the time of this writing, not possible, and + would be rather useless: a compiler—probably a + legitimate task—can easily use almost 100% of a CPU + for some time. + + + + + + + filesize + + + This is the maximum size of a file the user may possess. + Unlike disk quotas, this limit is + enforced on individual files, not the set of all files a user + owns. + + + + + maxproc + + + This is the maximum number of processes a user may be + running. This includes foreground and background processes + alike. For obvious reasons, this may not be larger than the + system limit specified by the kern.maxproc + sysctl. Also note that setting this too small may hinder a + user's productivity: it is often useful to be logged in + multiple times or execute pipelines. Some tasks, such as + compiling a large program, also spawn multiple processes (e.g., + &man.make.1;, &man.cc.1;, and other intermediate + preproccesors). + + + + + memorylocked + + + This is the maximum amount a memory a process may have + requested to be locked into main memory (e.g., see + &man.mlock.2;). Some system-critical programs, such as + &man.amd.8;, do this so that their getting swapped out does not + contribute to a system's thrashing in time of trouble. + + + + + memoryuse + + + This is the maximum amount of memory a process may consume + at any given time. It includes both core memory and swap + usage. This is not a catch-all limit for restricting memory + consumption, but it is a good start. + + + + + openfiles + + + This is the maximum amount of files a process may have + open. In FreeBSD, files are also used to represent sockets and + IPC channels; thus, be careful not to set this too low. The + system-wide limit for this is defined by the + kern.maxfiles sysctl. + + + + + sbsize + + + This is the limit on the amount of network memory, and thus + mbufs, a user may consume. This originated as a response to an + old DoS attack by creating a lot of sockets, but can be + generally used to limit network communications. + + + + + stacksize + + + This is the maximum size a process' stack may grow to. + This alone is not sufficient to limit the amount of memory a + program may use; consequently, it should be used in conjunction + with other limits. + + + + + There are a few other things to remember when setting resource + limits. Following are some general tips, suggestions, and + miscellaneous comments. + + + + Processes started at system startup by + /etc/rc are assigned to the + daemon login class. + + + + Although the /etc/login.conf that comes + with the system is a good source of reasonable values for most + limits, only you, the administrator, can know what is appropriate + for your system. Setting a limit too high may open your system + up to abuse, while setting it too low may put a strain on + productivity. + + + + Users of the X Window System (X11) should probably be granted + more resources than other users. X11 by itself takes a lot of + resources, but it also encourages users to run more programs + simultaneously. + + + + Remember that many limits apply to individual processes, not + the user as a whole. For example, setting openfiles to 50 means + that each process the user runs may open up to 50 files. Thus, + the gross amount of files a user may open is the value of + openfiles multiplied by the value of + maxproc. This also applies to memory + consumption. + + + + For further information on resource limits and login classes and + capabilities in general, please consult the relevant manual pages: + &man.cap.mkdb.1;, &man.getrlimit.2;, &man.login.conf.5;. + + + + Personalizing Users Localization is an environment set up by the system administrator or user to accommodate different languages, character sets, date and time standards, and so on. This is discussed in the localization chapter. diff --git a/en_US.ISO_8859-1/books/handbook/users/chapter.sgml b/en_US.ISO_8859-1/books/handbook/users/chapter.sgml index 880375942a..b91dbf7464 100644 --- a/en_US.ISO_8859-1/books/handbook/users/chapter.sgml +++ b/en_US.ISO_8859-1/books/handbook/users/chapter.sgml @@ -1,425 +1,634 @@ Users and Basic Account Management Synopsis Contributed by &a.nbm; February 2000. All access to the system is achieved via accounts, and all processes are run by users, so user and account management are of integral importance on FreeBSD systems. There are three main types of accounts; the Superuser, system users, and user accounts. The Superuser account, usually called root, is used to manage the system with no limitations on privileges. System users run services. Finally, user accounts are used by real people, who log on, read mail, and so forth. The Superuser Account The superuser account, usually called root, comes preconfigured, and facilitates system administration, and should not be used for day-to-day tasks like sending and receiving mail, general exploration of the system, or programming. This is because the superuser, unlike normal user accounts, can operate without limits, and misuse of the superuser account may result in spectacular disasters. User accounts are unable to destroy the system by mistake, so it is generally best to use normal user accounts whenever possible, unless you especially need the extra privilege. In addition, always double and triple-check commands you issue as the superuser, since an extra space or missing character can mean irreparable data loss. Those extra privileges you needed when you decided to change to the superuser mean that the safeguards of your normal user account no longer apply. So, the first thing you should do after reading this chapter, is to create an unprivileged user account for yourself for general usage, if you haven't already. This applies equally whether you're running a multi-user or single-user machine. Later in this chapter, we discuss how to create additional accounts, and how to change between the normal user and superuser. System Accounts System users are those used to run services such as DNS, mail, web servers, and so forth. The reason for this is security; if all services ran as the superuser, they could act without restriction. Examples of system users are daemon, operator, bind (for the Domain Name Service), and news. Often sysadmins create httpd to run web servers they install. nobody is the generic unprivileged system user, but the more services that use nobody, the more privileged it becomes. User Accounts User accounts are the primary means of access for real people to the system, and these accounts insulate the user and the environment, preventing the users from damaging the system or other users, and allowing users to customize their environment without affecting others. Every person accessing your system should have their own unique user account. This allows you to find out who is doing what, and prevent people from clobbering each others' settings, and reading mail meant for the other, and so forth. Each user can set up their own environment to accommodate their use of the system, by using alternate shells, editors, key bindings, and language. Modifying Accounts pw is a powerful and flexible means to modify accounts, but adduser is recommended for creating new accounts, and rmuser for deleting accounts. chpass allows both the system administrator and normal users to adjust passwords, shells, and personal information. passwd is the more common means to change passwords specifically, however. adduser adduser is a simple program for adding new users. It creates passwd and group entries for the user, as well as creating their home directory, copy in some default dotfiles from /usr/share/skel, and can optionally mail the user a welcome message. To create the initial configuration file, use adduser -s -config_create. The makes adduser default to quiet. We use later when we want to change defaults. Next, we configure adduser defaults, and create our first user account, since using root for normal usage is evil and nasty. Changing the configuration for adduser &prompt.root; adduser -v Use option ``-silent'' if you don't want to see all warnings and questions. Check /etc/shells Check /etc/master.passwd Check /etc/group Enter your default shell: csh date no sh tcsh [sh]: tcsh Your default shell is: tcsh -> /usr/local/bin/tcsh Enter your default HOME partition: [/home]: Copy dotfiles from: /usr/share/skel no [/usr/share/skel]: Send message from file: /etc/adduser.message no [/etc/adduser.message]: no Do not send message Use passwords (y/n) [y]: y Write your changes to /etc/adduser.conf? (y/n) [n]: y Ok, let's go. Don't worry about mistakes. I will give you the chance later to correct any input. Enter username [a-z0-9_-]: jru Enter full name []: J. Random User Enter shell csh date no sh tcsh [tcsh]: Enter home directory (full path) [/home/jru]: Uid [1001]: Enter login class: default []: Login group jru [jru]: Login group is ``jru''. Invite jru into other groups: guest no [no]: wheel Enter password []: Enter password again []: Name: jru Password: **** Fullname: J. Random User Uid: 1007 Gid: 1007 (jru) Class: Groups: jru wheel HOME: /home/jru Shell: /usr/local/bin/tcsh OK? (y/n) [y]: y Added user ``jru'' Copy files from /usr/share/skel to /home/jru Add another user? (y/n) [y]: n Goodbye! &prompt.root; In summary, we changed the default shell to tcsh (an additional shell found in packages), and turned off the sending of a welcome mail to added users. We then saved the configuration, and then created an account for jru, and we made sure jru is in wheel group (which we'll see is important later). The password you type in isn't echoed, nor are asterisks displayed. Make sure you don't mistype the password twice :-) Just use adduser without arguments from now on, and you won't have to go through changing the defaults. If the program asks you to change the defaults, exit the program, and try the option. rmuser rmuser removes users from the system, including any traces beyond the user database. rmuser performs the following steps: Removes the user's &man.crontab.1; entry (if any). Removes any &man.at.1; jobs belonging to the user. Kills all processes owned by the user Removes the user from the system's local password file. Removes the user's home directory (if it is owned by the user) Removes the incoming mail files belonging to the user from /var/mail. Removes all files owned by the user from temporary file storage areas such as /tmp. Finally, removes the username from all groups to which it belongs in /etc/group. If a group becomes empty and the group name is the same as the username, the group is removed; this complements the per-user unique groups created by &man.adduser.8;. rmuser can't be used to remove superuser accounts, since that is almost always an indication of massive destruction. By default, an interactive mode is used, which attempts to make sure you know what you're doing. rmuser interactive account removal &prompt.root; rmuser jru Matching password entry: jru:*:1000:1000::0:0:J. Random User:/home/jru:/usr/local/bin/tcsh Is this the entry you wish to remove? y Remove user's home directory (/home/jru)? y Updating password file, updating databases, done. Updating group file: trusted (removing group jru -- personal group is empty) done. Removing user's incoming mail file /var/mail/jru: done. Removing files belonging to jru from /tmp: done. Removing files belonging to jru from /var/tmp: done. Removing files belonging to jru from /var/tmp/vi.recover: done. &prompt.root; pw pw is a command line utility to create, remove, modify, and display users and groups, and functions as an editor of the system user and group files. It is designed to be useful both as a directly executed command and for use from shell scripts. &man.pw.8; has all the information. chpass chpass changes user database information such as passwords, shells, and personal information. Only system administrators, as the superuser, may change other users' information and passwords with chpass. Passed no options, besides the optional username, chpass displays an editor containing user information, and upon exit from the editor, attempts to change the information in the user database. Interactive chpass by Superuser #Changing user database information for jru. Login: jru Password: * Uid [#]: 1000 Gid [# or name]: 1000 Change [month day year]: Expire [month day year]: Class: Home directory: /home/jru Shell: /usr/local/bin/tcsh Full Name: J. Random User Office Location: Office Phone: Home Phone: Other information: The normal user can change only a small subsection of this information, and only for themselves. Interactive chpass by Normal User #Changing user database information for jru. Shell: /usr/local/bin/tcsh Full Name: J. Random User Office Location: Office Phone: Home Phone: Other information: chfn and chsh are just links to chpass, as are ypchpass, ypchfn, and ypchsh. NIS support is automatic, so specifying the yp before the command is not necessary. passwd passwd is the usual way to change your own password as a user, or another user's password as the superuser. Users must type in their original password before changing their password, to prevent an unauthorized person from changing their password when the user is away from their console. passwd &prompt.user; passwd Changing local password for jru. Old password: New password: Retype new password: passwd: updating the database... passwd: done &prompt.root; passwd jru Changing local password for jru. New password: Retype new password: passwd: updating the database... passwd: done yppasswd is just a link to passwd. NIS support is automatic, so specifying the yp before the command is not necessary. - - Limiting and Personalizing Users + + Limiting Users + + If you run a multi-user system, chances are that you do not trust + all of your users not to damage your system. FreeBSD provides a + number of ways a system administrator can limit the amount of system + resources an individual user can use. These limits are generally + divided into two sections: disk quotas, and other resources + limits. + + Disk quotas are a way for the system administrator to tell the + filesystem the amount of disk space a user may use; moreover, they + provide a way to quickly check on the disk usage of a user without + having to calculate it every time. Quotas are discussed in . + + The other resource limits include ways to limit the amount of + CPU, memory, and other resources a user may consume. These are + defined using login classes and are discussed here. + + Login classes are defined in + /etc/login.conf. The precise semantics are + beyond the scope of this section, but are described in detail in the + &man.login.conf.5; manual page. It is sufficient to say that each + user can is assigned to a login class (default by + default), and that each login class has a set of login capabilities + associated with it. A login capability is a + name=value + pair, where name is a well-known + identifier and value is an arbitrary + string processed accordingly depending on the name. Setting up login + classes and capabilities is rather straight-forward, and is also + described in &man.login.conf.5;. + + Resource limits are different from plain vanilla login + capabilities in two ways. First, for every limit, there is a soft + (current) and hard limit. A soft limit may be adjusted by the user + or application, but may be no higher than the hard limit. The latter + may be lowered by the user, but never raised. Second, most resource + limits apply per process to a specific user, not the user as a whole. + Note, however, that these differences are mandated by the specific + handling of the limits, not by the implementation of the login + capability framework (i.e., they are not really + a special case of login capabilities). + + And so, without further ado, below are the most commonly used + resource limits (the rest, along with all the other login + capabilities, may be found in &man.login.conf.5;). + + + + coredumpsize + + + The limit on the size of a core file generated by a program + is, for obvious reasons, subordinate to other limits on disk + usage (e.g., filesize, or disk quotas). + Nevertheless, it is often used as a less-severe method of + controlling disk space consumption: since users do not generate + core files themselves, and often do not delete them, setting this + may save them from running out of disk space should a large + program (e.g., Emacs) crash. + + + + + cputime + + + This is the maximum amount of CPU time a user's process may + consume. Offending processes will be killed by the kernel. - Quotas allow the system administrator to set disk usage - maximums, and users to check their disk usage, if quotas are - used on the system. Quotas are discussed in their own chapter. + + This is a limit on CPU time + consumed, not percentage of the CPU as displayed in some + fields by &man.top.1; and &man.ps.1;. A limit on the + latter is, at the time of this writing, not possible, and + would be rather useless: a compiler—probably a + legitimate task—can easily use almost 100% of a CPU + for some time. + + + + + + + filesize + + + This is the maximum size of a file the user may possess. + Unlike disk quotas, this limit is + enforced on individual files, not the set of all files a user + owns. + + + + + maxproc + + + This is the maximum number of processes a user may be + running. This includes foreground and background processes + alike. For obvious reasons, this may not be larger than the + system limit specified by the kern.maxproc + sysctl. Also note that setting this too small may hinder a + user's productivity: it is often useful to be logged in + multiple times or execute pipelines. Some tasks, such as + compiling a large program, also spawn multiple processes (e.g., + &man.make.1;, &man.cc.1;, and other intermediate + preproccesors). + + + + + memorylocked + + + This is the maximum amount a memory a process may have + requested to be locked into main memory (e.g., see + &man.mlock.2;). Some system-critical programs, such as + &man.amd.8;, do this so that their getting swapped out does not + contribute to a system's thrashing in time of trouble. + + + + + memoryuse + + + This is the maximum amount of memory a process may consume + at any given time. It includes both core memory and swap + usage. This is not a catch-all limit for restricting memory + consumption, but it is a good start. + + + + + openfiles + + + This is the maximum amount of files a process may have + open. In FreeBSD, files are also used to represent sockets and + IPC channels; thus, be careful not to set this too low. The + system-wide limit for this is defined by the + kern.maxfiles sysctl. + + + + + sbsize + + + This is the limit on the amount of network memory, and thus + mbufs, a user may consume. This originated as a response to an + old DoS attack by creating a lot of sockets, but can be + generally used to limit network communications. + + + + + stacksize + + + This is the maximum size a process' stack may grow to. + This alone is not sufficient to limit the amount of memory a + program may use; consequently, it should be used in conjunction + with other limits. + + + + + There are a few other things to remember when setting resource + limits. Following are some general tips, suggestions, and + miscellaneous comments. + + + + Processes started at system startup by + /etc/rc are assigned to the + daemon login class. + + + + Although the /etc/login.conf that comes + with the system is a good source of reasonable values for most + limits, only you, the administrator, can know what is appropriate + for your system. Setting a limit too high may open your system + up to abuse, while setting it too low may put a strain on + productivity. + + + + Users of the X Window System (X11) should probably be granted + more resources than other users. X11 by itself takes a lot of + resources, but it also encourages users to run more programs + simultaneously. + + + + Remember that many limits apply to individual processes, not + the user as a whole. For example, setting openfiles to 50 means + that each process the user runs may open up to 50 files. Thus, + the gross amount of files a user may open is the value of + openfiles multiplied by the value of + maxproc. This also applies to memory + consumption. + + + + For further information on resource limits and login classes and + capabilities in general, please consult the relevant manual pages: + &man.cap.mkdb.1;, &man.getrlimit.2;, &man.login.conf.5;. + + + + Personalizing Users Localization is an environment set up by the system administrator or user to accommodate different languages, character sets, date and time standards, and so on. This is discussed in the localization chapter.