brintos

brintos / linux-shallow public Read only

0
0
Text · 11.9 KiB · 47499a1 Raw
335 lines · plain
1===============================2Documentation for /proc/sys/fs/3===============================4 5Copyright (c) 1998, 1999,  Rik van Riel <riel@nl.linux.org>6 7Copyright (c) 2009,        Shen Feng<shen@cn.fujitsu.com>8 9For general info and legal blurb, please look in intro.rst.10 11------------------------------------------------------------------------------12 13This file contains documentation for the sysctl files and directories14in ``/proc/sys/fs/``.15 16The files in this directory can be used to tune and monitor17miscellaneous and general things in the operation of the Linux18kernel. Since some of the files *can* be used to screw up your19system, it is advisable to read both documentation and source20before actually making adjustments.21 221. /proc/sys/fs23===============24 25Currently, these files might (depending on your configuration)26show up in ``/proc/sys/fs``:27 28.. contents:: :local:29 30 31aio-nr & aio-max-nr32-------------------33 34``aio-nr`` shows the current system-wide number of asynchronous io35requests.  ``aio-max-nr`` allows you to change the maximum value36``aio-nr`` can grow to.  If ``aio-nr`` reaches ``aio-nr-max`` then37``io_setup`` will fail with ``EAGAIN``.  Note that raising38``aio-max-nr`` does not result in the39pre-allocation or re-sizing of any kernel data structures.40 41 42dentry-state43------------44 45This file shows the values in ``struct dentry_stat_t``, as defined in46``fs/dcache.c``::47 48  struct dentry_stat_t dentry_stat {49        long nr_dentry;50        long nr_unused;51        long age_limit;         /* age in seconds */52        long want_pages;        /* pages requested by system */53        long nr_negative;       /* # of unused negative dentries */54        long dummy;             /* Reserved for future use */55  };56 57Dentries are dynamically allocated and deallocated.58 59``nr_dentry`` shows the total number of dentries allocated (active60+ unused). ``nr_unused shows`` the number of dentries that are not61actively used, but are saved in the LRU list for future reuse.62 63``age_limit`` is the age in seconds after which dcache entries64can be reclaimed when memory is short and ``want_pages`` is65nonzero when ``shrink_dcache_pages()`` has been called and the66dcache isn't pruned yet.67 68``nr_negative`` shows the number of unused dentries that are also69negative dentries which do not map to any files. Instead,70they help speeding up rejection of non-existing files provided71by the users.72 73 74file-max & file-nr75------------------76 77The value in ``file-max`` denotes the maximum number of file-78handles that the Linux kernel will allocate. When you get lots79of error messages about running out of file handles, you might80want to increase this limit.81 82Historically,the kernel was able to allocate file handles83dynamically, but not to free them again. The three values in84``file-nr`` denote the number of allocated file handles, the number85of allocated but unused file handles, and the maximum number of86file handles. Linux 2.6 and later always reports 0 as the number of free87file handles -- this is not an error, it just means that the88number of allocated file handles exactly matches the number of89used file handles.90 91Attempts to allocate more file descriptors than ``file-max`` are92reported with ``printk``, look for::93 94  VFS: file-max limit <number> reached95 96in the kernel logs.97 98 99inode-nr & inode-state100----------------------101 102As with file handles, the kernel allocates the inode structures103dynamically, but can't free them yet.104 105The file ``inode-nr`` contains the first two items from106``inode-state``, so we'll skip to that file...107 108``inode-state`` contains three actual numbers and four dummies.109The actual numbers are, in order of appearance, ``nr_inodes``,110``nr_free_inodes`` and ``preshrink``.111 112``nr_inodes`` stands for the number of inodes the system has113allocated.114 115``nr_free_inodes`` represents the number of free inodes (?) and116preshrink is nonzero when the117system needs to prune the inode list instead of allocating118more.119 120 121mount-max122---------123 124This denotes the maximum number of mounts that may exist125in a mount namespace.126 127 128nr_open129-------130 131This denotes the maximum number of file-handles a process can132allocate. Default value is 1024*1024 (1048576) which should be133enough for most machines. Actual limit depends on ``RLIMIT_NOFILE``134resource limit.135 136 137overflowgid & overflowuid138-------------------------139 140Some filesystems only support 16-bit UIDs and GIDs, although in Linux141UIDs and GIDs are 32 bits. When one of these filesystems is mounted142with writes enabled, any UID or GID that would exceed 65535 is translated143to a fixed value before being written to disk.144 145These sysctls allow you to change the value of the fixed UID and GID.146The default is 65534.147 148 149pipe-user-pages-hard150--------------------151 152Maximum total number of pages a non-privileged user may allocate for pipes.153Once this limit is reached, no new pipes may be allocated until usage goes154below the limit again. When set to 0, no limit is applied, which is the default155setting.156 157 158pipe-user-pages-soft159--------------------160 161Maximum total number of pages a non-privileged user may allocate for pipes162before the pipe size gets limited to a single page. Once this limit is reached,163new pipes will be limited to a single page in size for this user in order to164limit total memory usage, and trying to increase them using ``fcntl()`` will be165denied until usage goes below the limit again. The default value allows to166allocate up to 1024 pipes at their default size. When set to 0, no limit is167applied.168 169 170protected_fifos171---------------172 173The intent of this protection is to avoid unintentional writes to174an attacker-controlled FIFO, where a program expected to create a regular175file.176 177When set to "0", writing to FIFOs is unrestricted.178 179When set to "1" don't allow ``O_CREAT`` open on FIFOs that we don't own180in world writable sticky directories, unless they are owned by the181owner of the directory.182 183When set to "2" it also applies to group writable sticky directories.184 185This protection is based on the restrictions in Openwall.186 187 188protected_hardlinks189--------------------190 191A long-standing class of security issues is the hardlink-based192time-of-check-time-of-use race, most commonly seen in world-writable193directories like ``/tmp``. The common method of exploitation of this flaw194is to cross privilege boundaries when following a given hardlink (i.e. a195root process follows a hardlink created by another user). Additionally,196on systems without separated partitions, this stops unauthorized users197from "pinning" vulnerable setuid/setgid files against being upgraded by198the administrator, or linking to special files.199 200When set to "0", hardlink creation behavior is unrestricted.201 202When set to "1" hardlinks cannot be created by users if they do not203already own the source file, or do not have read/write access to it.204 205This protection is based on the restrictions in Openwall and grsecurity.206 207 208protected_regular209-----------------210 211This protection is similar to `protected_fifos`_, but it212avoids writes to an attacker-controlled regular file, where a program213expected to create one.214 215When set to "0", writing to regular files is unrestricted.216 217When set to "1" don't allow ``O_CREAT`` open on regular files that we218don't own in world writable sticky directories, unless they are219owned by the owner of the directory.220 221When set to "2" it also applies to group writable sticky directories.222 223 224protected_symlinks225------------------226 227A long-standing class of security issues is the symlink-based228time-of-check-time-of-use race, most commonly seen in world-writable229directories like ``/tmp``. The common method of exploitation of this flaw230is to cross privilege boundaries when following a given symlink (i.e. a231root process follows a symlink belonging to another user). For a likely232incomplete list of hundreds of examples across the years, please see:233https://cve.mitre.org/cgi-bin/cvekey.cgi?keyword=/tmp234 235When set to "0", symlink following behavior is unrestricted.236 237When set to "1" symlinks are permitted to be followed only when outside238a sticky world-writable directory, or when the uid of the symlink and239follower match, or when the directory owner matches the symlink's owner.240 241This protection is based on the restrictions in Openwall and grsecurity.242 243 244suid_dumpable245-------------246 247This value can be used to query and set the core dump mode for setuid248or otherwise protected/tainted binaries. The modes are249 250=   ==========  ===============================================================2510   (default)	Traditional behaviour. Any process which has changed252		privilege levels or is execute only will not be dumped.2531   (debug)	All processes dump core when possible. The core dump is254		owned by the current user and no security is applied. This is255		intended for system debugging situations only.256		Ptrace is unchecked.257		This is insecure as it allows regular users to examine the258		memory contents of privileged processes.2592   (suidsafe)	Any binary which normally would not be dumped is dumped260		anyway, but only if the ``core_pattern`` kernel sysctl (see261		:ref:`Documentation/admin-guide/sysctl/kernel.rst <core_pattern>`)262		is set to263		either a pipe handler or a fully qualified path. (For more264		details on this limitation, see CVE-2006-2451.) This mode is265		appropriate when administrators are attempting to debug266		problems in a normal environment, and either have a core dump267		pipe handler that knows to treat privileged core dumps with268		care, or specific directory defined for catching core dumps.269		If a core dump happens without a pipe handler or fully270		qualified path, a message will be emitted to syslog warning271		about the lack of a correct setting.272=   ==========  ===============================================================273 274 275 2762. /proc/sys/fs/binfmt_misc277===========================278 279Documentation for the files in ``/proc/sys/fs/binfmt_misc`` is280in Documentation/admin-guide/binfmt-misc.rst.281 282 2833. /proc/sys/fs/mqueue - POSIX message queues filesystem284========================================================285 286 287The "mqueue"  filesystem provides  the necessary kernel features to enable the288creation of a  user space  library that  implements  the  POSIX message queues289API (as noted by the  MSG tag in the  POSIX 1003.1-2001 version  of the System290Interfaces specification.)291 292The "mqueue" filesystem contains values for determining/setting the293amount of resources used by the file system.294 295``/proc/sys/fs/mqueue/queues_max`` is a read/write file for296setting/getting the maximum number of message queues allowed on the297system.298 299``/proc/sys/fs/mqueue/msg_max`` is a read/write file for300setting/getting the maximum number of messages in a queue value.  In301fact it is the limiting value for another (user) limit which is set in302``mq_open`` invocation.  This attribute of a queue must be less than303or equal to ``msg_max``.304 305``/proc/sys/fs/mqueue/msgsize_max`` is a read/write file for306setting/getting the maximum message size value (it is an attribute of307every message queue, set during its creation).308 309``/proc/sys/fs/mqueue/msg_default`` is a read/write file for310setting/getting the default number of messages in a queue value if the311``attr`` parameter of ``mq_open(2)`` is ``NULL``. If it exceeds312``msg_max``, the default value is initialized to ``msg_max``.313 314``/proc/sys/fs/mqueue/msgsize_default`` is a read/write file for315setting/getting the default message size value if the ``attr``316parameter of ``mq_open(2)`` is ``NULL``. If it exceeds317``msgsize_max``, the default value is initialized to ``msgsize_max``.318 3194. /proc/sys/fs/epoll - Configuration options for the epoll interface320=====================================================================321 322This directory contains configuration options for the epoll(7) interface.323 324max_user_watches325----------------326 327Every epoll file descriptor can store a number of files to be monitored328for event readiness. Each one of these monitored files constitutes a "watch".329This configuration option sets the maximum number of "watches" that are330allowed for each user.331Each "watch" costs roughly 90 bytes on a 32-bit kernel, and roughly 160 bytes332on a 64-bit one.333The current default value for ``max_user_watches`` is 4% of the334available low memory, divided by the "watch" cost in bytes.335