| 1 | ===============================
|
| 2 | Documentation for /proc/sys/fs/
|
| 3 | ===============================
|
| 4 |
|
| 5 | Copyright (c) 1998, 1999, Rik van Riel <[email protected]>
|
| 6 |
|
| 7 | Copyright (c) 2009, Shen Feng<[email protected]>
|
| 8 |
|
| 9 | For general info and legal blurb, please look in intro.rst.
|
| 10 |
|
| 11 | ------------------------------------------------------------------------------
|
| 12 |
|
| 13 | This file contains documentation for the sysctl files and directories
|
| 14 | in ``/proc/sys/fs/``.
|
| 15 |
|
| 16 | The files in this directory can be used to tune and monitor
|
| 17 | miscellaneous and general things in the operation of the Linux
|
| 18 | kernel. Since some of the files *can* be used to screw up your
|
| 19 | system, it is advisable to read both documentation and source
|
| 20 | before actually making adjustments.
|
| 21 |
|
| 22 | 1. /proc/sys/fs
|
| 23 | ===============
|
| 24 |
|
| 25 | Currently, these files might (depending on your configuration)
|
| 26 | show up in ``/proc/sys/fs``:
|
| 27 |
|
| 28 | .. contents:: :local:
|
| 29 |
|
| 30 |
|
| 31 | aio-nr & aio-max-nr
|
| 32 | -------------------
|
| 33 |
|
| 34 | ``aio-nr`` shows the current system-wide number of asynchronous io
|
| 35 | requests. ``aio-max-nr`` allows you to change the maximum value
|
| 36 | ``aio-nr`` can grow to. If ``aio-nr`` reaches ``aio-nr-max`` then
|
| 37 | ``io_setup`` will fail with ``EAGAIN``. Note that raising
|
| 38 | ``aio-max-nr`` does not result in the
|
| 39 | pre-allocation or re-sizing of any kernel data structures.
|
| 40 |
|
| 41 | dentry-negative
|
| 42 | ----------------------------
|
| 43 |
|
| 44 | Policy for negative dentries. Set to 1 to always delete the dentry when a
|
| 45 | file is removed, and 0 to disable it. By default, this behavior is disabled.
|
| 46 |
|
| 47 | dentry-state
|
| 48 | ------------
|
| 49 |
|
| 50 | This file shows the values in ``struct dentry_stat_t``, as defined in
|
| 51 | ``fs/dcache.c``::
|
| 52 |
|
| 53 | struct dentry_stat_t dentry_stat {
|
| 54 | long nr_dentry;
|
| 55 | long nr_unused;
|
| 56 | long age_limit; /* age in seconds */
|
| 57 | long want_pages; /* pages requested by system */
|
| 58 | long nr_negative; /* # of unused negative dentries */
|
| 59 | long dummy; /* Reserved for future use */
|
| 60 | };
|
| 61 |
|
| 62 | Dentries are dynamically allocated and deallocated.
|
| 63 |
|
| 64 | ``nr_dentry`` shows the total number of dentries allocated (active
|
| 65 | + unused). ``nr_unused shows`` the number of dentries that are not
|
| 66 | actively used, but are saved in the LRU list for future reuse.
|
| 67 |
|
| 68 | ``age_limit`` is the age in seconds after which dcache entries
|
| 69 | can be reclaimed when memory is short and ``want_pages`` is
|
| 70 | nonzero when ``shrink_dcache_pages()`` has been called and the
|
| 71 | dcache isn't pruned yet.
|
| 72 |
|
| 73 | ``nr_negative`` shows the number of unused dentries that are also
|
| 74 | negative dentries which do not map to any files. Instead,
|
| 75 | they help speeding up rejection of non-existing files provided
|
| 76 | by the users.
|
| 77 |
|
| 78 |
|
| 79 | file-max & file-nr
|
| 80 | ------------------
|
| 81 |
|
| 82 | The value in ``file-max`` denotes the maximum number of file-
|
| 83 | handles that the Linux kernel will allocate. When you get lots
|
| 84 | of error messages about running out of file handles, you might
|
| 85 | want to increase this limit.
|
| 86 |
|
| 87 | Historically,the kernel was able to allocate file handles
|
| 88 | dynamically, but not to free them again. The three values in
|
| 89 | ``file-nr`` denote the number of allocated file handles, the number
|
| 90 | of allocated but unused file handles, and the maximum number of
|
| 91 | file handles. Linux 2.6 and later always reports 0 as the number of free
|
| 92 | file handles -- this is not an error, it just means that the
|
| 93 | number of allocated file handles exactly matches the number of
|
| 94 | used file handles.
|
| 95 |
|
| 96 | Attempts to allocate more file descriptors than ``file-max`` are
|
| 97 | reported with ``printk``, look for::
|
| 98 |
|
| 99 | VFS: file-max limit <number> reached
|
| 100 |
|
| 101 | in the kernel logs.
|
| 102 |
|
| 103 |
|
| 104 | inode-nr & inode-state
|
| 105 | ----------------------
|
| 106 |
|
| 107 | As with file handles, the kernel allocates the inode structures
|
| 108 | dynamically, but can't free them yet.
|
| 109 |
|
| 110 | The file ``inode-nr`` contains the first two items from
|
| 111 | ``inode-state``, so we'll skip to that file...
|
| 112 |
|
| 113 | ``inode-state`` contains three actual numbers and four dummies.
|
| 114 | The actual numbers are, in order of appearance, ``nr_inodes``,
|
| 115 | ``nr_free_inodes`` and ``preshrink``.
|
| 116 |
|
| 117 | ``nr_inodes`` stands for the number of inodes the system has
|
| 118 | allocated.
|
| 119 |
|
| 120 | ``nr_free_inodes`` represents the number of free inodes (?) and
|
| 121 | preshrink is nonzero when the
|
| 122 | system needs to prune the inode list instead of allocating
|
| 123 | more.
|
| 124 |
|
| 125 |
|
| 126 | mount-max
|
| 127 | ---------
|
| 128 |
|
| 129 | This denotes the maximum number of mounts that may exist
|
| 130 | in a mount namespace.
|
| 131 |
|
| 132 |
|
| 133 | nr_open
|
| 134 | -------
|
| 135 |
|
| 136 | This denotes the maximum number of file-handles a process can
|
| 137 | allocate. Default value is 1024*1024 (1048576) which should be
|
| 138 | enough for most machines. Actual limit depends on ``RLIMIT_NOFILE``
|
| 139 | resource limit.
|
| 140 |
|
| 141 |
|
| 142 | overflowgid & overflowuid
|
| 143 | -------------------------
|
| 144 |
|
| 145 | Some filesystems only support 16-bit UIDs and GIDs, although in Linux
|
| 146 | UIDs and GIDs are 32 bits. When one of these filesystems is mounted
|
| 147 | with writes enabled, any UID or GID that would exceed 65535 is translated
|
| 148 | to a fixed value before being written to disk.
|
| 149 |
|
| 150 | These sysctls allow you to change the value of the fixed UID and GID.
|
| 151 | The default is 65534.
|
| 152 |
|
| 153 |
|
| 154 | pipe-user-pages-hard
|
| 155 | --------------------
|
| 156 |
|
| 157 | Maximum total number of pages a non-privileged user may allocate for pipes.
|
| 158 | Once this limit is reached, no new pipes may be allocated until usage goes
|
| 159 | below the limit again. When set to 0, no limit is applied, which is the default
|
| 160 | setting.
|
| 161 |
|
| 162 |
|
| 163 | pipe-user-pages-soft
|
| 164 | --------------------
|
| 165 |
|
| 166 | Maximum total number of pages a non-privileged user may allocate for pipes
|
| 167 | before the pipe size gets limited to two pages. Once this limit is reached,
|
| 168 | new pipes will be limited to two pages in size for this user in order to
|
| 169 | limit total memory usage, and trying to increase them using ``fcntl()`` will be
|
| 170 | denied until usage goes below the limit again. The default value allows to
|
| 171 | allocate up to 1024 pipes at their default size. When set to 0, no limit is
|
| 172 | applied.
|
| 173 |
|
| 174 |
|
| 175 | protected_fifos
|
| 176 | ---------------
|
| 177 |
|
| 178 | The intent of this protection is to avoid unintentional writes to
|
| 179 | an attacker-controlled FIFO, where a program expected to create a regular
|
| 180 | file.
|
| 181 |
|
| 182 | When set to "0", writing to FIFOs is unrestricted.
|
| 183 |
|
| 184 | When set to "1" don't allow ``O_CREAT`` open on FIFOs that we don't own
|
| 185 | in world writable sticky directories, unless they are owned by the
|
| 186 | owner of the directory.
|
| 187 |
|
| 188 | When set to "2" it also applies to group writable sticky directories.
|
| 189 |
|
| 190 | This protection is based on the restrictions in Openwall.
|
| 191 |
|
| 192 |
|
| 193 | protected_hardlinks
|
| 194 | --------------------
|
| 195 |
|
| 196 | A long-standing class of security issues is the hardlink-based
|
| 197 | time-of-check-time-of-use race, most commonly seen in world-writable
|
| 198 | directories like ``/tmp``. The common method of exploitation of this flaw
|
| 199 | is to cross privilege boundaries when following a given hardlink (i.e. a
|
| 200 | root process follows a hardlink created by another user). Additionally,
|
| 201 | on systems without separated partitions, this stops unauthorized users
|
| 202 | from "pinning" vulnerable setuid/setgid files against being upgraded by
|
| 203 | the administrator, or linking to special files.
|
| 204 |
|
| 205 | When set to "0", hardlink creation behavior is unrestricted.
|
| 206 |
|
| 207 | When set to "1" hardlinks cannot be created by users if they do not
|
| 208 | already own the source file, or do not have read/write access to it.
|
| 209 |
|
| 210 | This protection is based on the restrictions in Openwall and grsecurity.
|
| 211 |
|
| 212 |
|
| 213 | protected_regular
|
| 214 | -----------------
|
| 215 |
|
| 216 | This protection is similar to `protected_fifos`_, but it
|
| 217 | avoids writes to an attacker-controlled regular file, where a program
|
| 218 | expected to create one.
|
| 219 |
|
| 220 | When set to "0", writing to regular files is unrestricted.
|
| 221 |
|
| 222 | When set to "1" don't allow ``O_CREAT`` open on regular files that we
|
| 223 | don't own in world writable sticky directories, unless they are
|
| 224 | owned by the owner of the directory.
|
| 225 |
|
| 226 | When set to "2" it also applies to group writable sticky directories.
|
| 227 |
|
| 228 |
|
| 229 | protected_symlinks
|
| 230 | ------------------
|
| 231 |
|
| 232 | A long-standing class of security issues is the symlink-based
|
| 233 | time-of-check-time-of-use race, most commonly seen in world-writable
|
| 234 | directories like ``/tmp``. The common method of exploitation of this flaw
|
| 235 | is to cross privilege boundaries when following a given symlink (i.e. a
|
| 236 | root process follows a symlink belonging to another user). For a likely
|
| 237 | incomplete list of hundreds of examples across the years, please see:
|
| 238 | https://cve.mitre.org/cgi-bin/cvekey.cgi?keyword=/tmp
|
| 239 |
|
| 240 | When set to "0", symlink following behavior is unrestricted.
|
| 241 |
|
| 242 | When set to "1" symlinks are permitted to be followed only when outside
|
| 243 | a sticky world-writable directory, or when the uid of the symlink and
|
| 244 | follower match, or when the directory owner matches the symlink's owner.
|
| 245 |
|
| 246 | This protection is based on the restrictions in Openwall and grsecurity.
|
| 247 |
|
| 248 |
|
| 249 | suid_dumpable
|
| 250 | -------------
|
| 251 |
|
| 252 | This value can be used to query and set the core dump mode for setuid
|
| 253 | or otherwise protected/tainted binaries. The modes are
|
| 254 |
|
| 255 | = ========== ===============================================================
|
| 256 | 0 (default) Traditional behaviour. Any process which has changed
|
| 257 | privilege levels or is execute only will not be dumped.
|
| 258 | 1 (debug) All processes dump core when possible. The core dump is
|
| 259 | owned by the current user and no security is applied. This is
|
| 260 | intended for system debugging situations only.
|
| 261 | Ptrace is unchecked.
|
| 262 | This is insecure as it allows regular users to examine the
|
| 263 | memory contents of privileged processes.
|
| 264 | 2 (suidsafe) Any binary which normally would not be dumped is dumped
|
| 265 | anyway, but only if the ``core_pattern`` kernel sysctl (see
|
| 266 | :ref:`Documentation/admin-guide/sysctl/kernel.rst <core_pattern>`)
|
| 267 | is set to
|
| 268 | either a pipe handler or a fully qualified path. (For more
|
| 269 | details on this limitation, see CVE-2006-2451.) This mode is
|
| 270 | appropriate when administrators are attempting to debug
|
| 271 | problems in a normal environment, and either have a core dump
|
| 272 | pipe handler that knows to treat privileged core dumps with
|
| 273 | care, or specific directory defined for catching core dumps.
|
| 274 | If a core dump happens without a pipe handler or fully
|
| 275 | qualified path, a message will be emitted to syslog warning
|
| 276 | about the lack of a correct setting.
|
| 277 | = ========== ===============================================================
|
| 278 |
|
| 279 |
|
| 280 |
|
| 281 | 2. /proc/sys/fs/binfmt_misc
|
| 282 | ===========================
|
| 283 |
|
| 284 | Documentation for the files in ``/proc/sys/fs/binfmt_misc`` is
|
| 285 | in Documentation/admin-guide/binfmt-misc.rst.
|
| 286 |
|
| 287 |
|
| 288 | 3. /proc/sys/fs/mqueue - POSIX message queues filesystem
|
| 289 | ========================================================
|
| 290 |
|
| 291 |
|
| 292 | The "mqueue" filesystem provides the necessary kernel features to enable the
|
| 293 | creation of a user space library that implements the POSIX message queues
|
| 294 | API (as noted by the MSG tag in the POSIX 1003.1-2001 version of the System
|
| 295 | Interfaces specification.)
|
| 296 |
|
| 297 | The "mqueue" filesystem contains values for determining/setting the
|
| 298 | amount of resources used by the file system.
|
| 299 |
|
| 300 | ``/proc/sys/fs/mqueue/queues_max`` is a read/write file for
|
| 301 | setting/getting the maximum number of message queues allowed on the
|
| 302 | system.
|
| 303 |
|
| 304 | ``/proc/sys/fs/mqueue/msg_max`` is a read/write file for
|
| 305 | setting/getting the maximum number of messages in a queue value. In
|
| 306 | fact it is the limiting value for another (user) limit which is set in
|
| 307 | ``mq_open`` invocation. This attribute of a queue must be less than
|
| 308 | or equal to ``msg_max``.
|
| 309 |
|
| 310 | ``/proc/sys/fs/mqueue/msgsize_max`` is a read/write file for
|
| 311 | setting/getting the maximum message size value (it is an attribute of
|
| 312 | every message queue, set during its creation).
|
| 313 |
|
| 314 | ``/proc/sys/fs/mqueue/msg_default`` is a read/write file for
|
| 315 | setting/getting the default number of messages in a queue value if the
|
| 316 | ``attr`` parameter of ``mq_open(2)`` is ``NULL``. If it exceeds
|
| 317 | ``msg_max``, the default value is initialized to ``msg_max``.
|
| 318 |
|
| 319 | ``/proc/sys/fs/mqueue/msgsize_default`` is a read/write file for
|
| 320 | setting/getting the default message size value if the ``attr``
|
| 321 | parameter of ``mq_open(2)`` is ``NULL``. If it exceeds
|
| 322 | ``msgsize_max``, the default value is initialized to ``msgsize_max``.
|
| 323 |
|
| 324 | 4. /proc/sys/fs/epoll - Configuration options for the epoll interface
|
| 325 | =====================================================================
|
| 326 |
|
| 327 | This directory contains configuration options for the epoll(7) interface.
|
| 328 |
|
| 329 | max_user_watches
|
| 330 | ----------------
|
| 331 |
|
| 332 | Every epoll file descriptor can store a number of files to be monitored
|
| 333 | for event readiness. Each one of these monitored files constitutes a "watch".
|
| 334 | This configuration option sets the maximum number of "watches" that are
|
| 335 | allowed for each user.
|
| 336 | Each "watch" costs roughly 90 bytes on a 32-bit kernel, and roughly 160 bytes
|
| 337 | on a 64-bit one.
|
| 338 | The current default value for ``max_user_watches`` is 4% of the
|
| 339 | available low memory, divided by the "watch" cost in bytes.
|
| 340 |
|
| 341 | 5. /proc/sys/fs/fuse - Configuration options for FUSE filesystems
|
| 342 | =====================================================================
|
| 343 |
|
| 344 | This directory contains the following configuration options for FUSE
|
| 345 | filesystems:
|
| 346 |
|
| 347 | ``/proc/sys/fs/fuse/max_pages_limit`` is a read/write file for
|
| 348 | setting/getting the maximum number of pages that can be used for servicing
|
| 349 | requests in FUSE.
|
| 350 |
|
| 351 | ``/proc/sys/fs/fuse/default_request_timeout`` is a read/write file for
|
| 352 | setting/getting the default timeout (in seconds) for a fuse server to
|
| 353 | reply to a kernel-issued request in the event where the server did not
|
| 354 | specify a timeout at mount. If the server set a timeout,
|
| 355 | then default_request_timeout will be ignored. The default
|
| 356 | "default_request_timeout" is set to 0. 0 indicates no default timeout.
|
| 357 | The maximum value that can be set is 65535.
|
| 358 |
|
| 359 | ``/proc/sys/fs/fuse/max_request_timeout`` is a read/write file for
|
| 360 | setting/getting the maximum timeout (in seconds) for a fuse server to
|
| 361 | reply to a kernel-issued request. A value greater than 0 automatically opts
|
| 362 | the server into a timeout that will be set to at most "max_request_timeout",
|
| 363 | even if the server did not specify a timeout and default_request_timeout is
|
| 364 | set to 0. If max_request_timeout is greater than 0 and the server set a timeout
|
| 365 | greater than max_request_timeout or default_request_timeout is set to a value
|
| 366 | greater than max_request_timeout, the system will use max_request_timeout as the
|
| 367 | timeout. 0 indicates no max request timeout. The maximum value that can be set
|
| 368 | is 65535.
|
| 369 |
|
| 370 | For timeouts, if the server does not respond to the request by the time
|
| 371 | the set timeout elapses, then the connection to the fuse server will be aborted.
|
| 372 | Please note that the timeouts are not 100% precise (eg you may set 60 seconds but
|
| 373 | the timeout may kick in after 70 seconds). The upper margin of error for the
|
| 374 | timeout is roughly FUSE_TIMEOUT_TIMER_FREQ seconds.
|