2019-05-19 12:07:45 +00:00
|
|
|
# SPDX-License-Identifier: GPL-2.0-only
|
2009-01-22 08:08:58 +00:00
|
|
|
config NFSD
|
|
|
|
|
tristate "NFS server support"
|
|
|
|
|
depends on INET
|
2009-01-29 15:23:57 +00:00
|
|
|
depends on FILE_LOCKING
|
2019-08-18 18:18:48 +00:00
|
|
|
depends on FSNOTIFY
|
2009-01-22 08:08:58 +00:00
|
|
|
select LOCKD
|
|
|
|
|
select SUNRPC
|
|
|
|
|
select EXPORTFS
|
|
|
|
|
select NFS_ACL_SUPPORT if NFSD_V2_ACL
|
2022-10-18 11:47:56 +00:00
|
|
|
select NFS_ACL_SUPPORT if NFSD_V3_ACL
|
kernel: conditionally support non-root users, groups and capabilities
There are a lot of embedded systems that run most or all of their
functionality in init, running as root:root. For these systems,
supporting multiple users is not necessary.
This patch adds a new symbol, CONFIG_MULTIUSER, that makes support for
non-root users, non-root groups, and capabilities optional. It is enabled
under CONFIG_EXPERT menu.
When this symbol is not defined, UID and GID are zero in any possible case
and processes always have all capabilities.
The following syscalls are compiled out: setuid, setregid, setgid,
setreuid, setresuid, getresuid, setresgid, getresgid, setgroups,
getgroups, setfsuid, setfsgid, capget, capset.
Also, groups.c is compiled out completely.
In kernel/capability.c, capable function was moved in order to avoid
adding two ifdef blocks.
This change saves about 25 KB on a defconfig build. The most minimal
kernels have total text sizes in the high hundreds of kB rather than
low MB. (The 25k goes down a bit with allnoconfig, but not that much.
The kernel was booted in Qemu. All the common functionalities work.
Adding users/groups is not possible, failing with -ENOSYS.
Bloat-o-meter output:
add/remove: 7/87 grow/shrink: 19/397 up/down: 1675/-26325 (-24650)
[akpm@linux-foundation.org: coding-style fixes]
Signed-off-by: Iulia Manda <iulia.manda21@gmail.com>
Reviewed-by: Josh Triplett <josh@joshtriplett.org>
Acked-by: Geert Uytterhoeven <geert@linux-m68k.org>
Tested-by: Paul E. McKenney <paulmck@linux.vnet.ibm.com>
Reviewed-by: Paul E. McKenney <paulmck@linux.vnet.ibm.com>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
2015-04-15 23:16:41 +00:00
|
|
|
depends on MULTIUSER
|
2009-01-22 08:08:58 +00:00
|
|
|
help
|
|
|
|
|
Choose Y here if you want to allow other computers to access
|
|
|
|
|
files residing on this system using Sun's Network File System
|
|
|
|
|
protocol. To compile the NFS server support as a module,
|
|
|
|
|
choose M here: the module will be called nfsd.
|
|
|
|
|
|
|
|
|
|
You may choose to use a user-space NFS server instead, in which
|
|
|
|
|
case you can choose N here.
|
|
|
|
|
|
|
|
|
|
To export local file systems using NFS, you also need to install
|
|
|
|
|
user space programs which can be found in the Linux nfs-utils
|
|
|
|
|
package, available from http://linux-nfs.org/. More detail about
|
|
|
|
|
the Linux NFS server implementation is available via the
|
|
|
|
|
exports(5) man page.
|
|
|
|
|
|
|
|
|
|
Below you can choose which versions of the NFS protocol are
|
|
|
|
|
available to clients mounting the NFS server on this system.
|
2022-10-18 11:47:56 +00:00
|
|
|
Support for NFS version 3 (RFC 1813) is always available when
|
2009-01-22 08:08:58 +00:00
|
|
|
CONFIG_NFSD is selected.
|
|
|
|
|
|
|
|
|
|
If unsure, say N.
|
|
|
|
|
|
2022-10-18 11:47:56 +00:00
|
|
|
config NFSD_V2
|
|
|
|
|
bool "NFS server support for NFS version 2 (DEPRECATED)"
|
2009-01-22 08:08:58 +00:00
|
|
|
depends on NFSD
|
2022-10-18 11:47:56 +00:00
|
|
|
default n
|
|
|
|
|
help
|
|
|
|
|
NFSv2 (RFC 1094) was the first publicly-released version of NFS.
|
|
|
|
|
Unless you are hosting ancient (1990's era) NFS clients, you don't
|
|
|
|
|
need this.
|
|
|
|
|
|
|
|
|
|
If unsure, say N.
|
|
|
|
|
|
|
|
|
|
config NFSD_V2_ACL
|
|
|
|
|
bool "NFS server support for the NFSv2 ACL protocol extension"
|
|
|
|
|
depends on NFSD_V2
|
2009-01-22 08:08:58 +00:00
|
|
|
|
|
|
|
|
config NFSD_V3_ACL
|
|
|
|
|
bool "NFS server support for the NFSv3 ACL protocol extension"
|
2022-02-06 17:25:47 +00:00
|
|
|
depends on NFSD
|
2009-01-22 08:08:58 +00:00
|
|
|
help
|
|
|
|
|
Solaris NFS servers support an auxiliary NFSv3 ACL protocol that
|
|
|
|
|
never became an official part of the NFS version 3 protocol.
|
|
|
|
|
This protocol extension allows applications on NFS clients to
|
|
|
|
|
manipulate POSIX Access Control Lists on files residing on NFS
|
|
|
|
|
servers. NFS servers enforce POSIX ACLs on local files whether
|
|
|
|
|
this protocol is available or not.
|
|
|
|
|
|
|
|
|
|
This option enables support in your system's NFS server for the
|
|
|
|
|
NFSv3 ACL protocol extension allowing NFS clients to manipulate
|
|
|
|
|
POSIX ACLs on files exported by your system's NFS server. NFS
|
|
|
|
|
clients which support the Solaris NFSv3 ACL protocol can then
|
|
|
|
|
access and modify ACLs on your NFS server.
|
|
|
|
|
|
|
|
|
|
To store ACLs on your NFS server, you also need to enable ACL-
|
|
|
|
|
related CONFIG options for your local file systems of choice.
|
|
|
|
|
|
|
|
|
|
If unsure, say N.
|
|
|
|
|
|
|
|
|
|
config NFSD_V4
|
2013-01-17 02:54:14 +00:00
|
|
|
bool "NFS server support for NFS version 4"
|
|
|
|
|
depends on NFSD && PROC_FS
|
2009-01-22 08:08:58 +00:00
|
|
|
select FS_POSIX_ACL
|
2010-09-12 23:57:50 +00:00
|
|
|
select SUNRPC_GSS
|
2021-02-19 21:56:10 +00:00
|
|
|
select CRYPTO
|
2019-12-04 06:13:22 +00:00
|
|
|
select CRYPTO_MD5
|
2019-11-12 19:01:55 +00:00
|
|
|
select CRYPTO_SHA256
|
2014-09-12 20:40:20 +00:00
|
|
|
select GRACE_PERIOD
|
2021-01-28 06:42:26 +00:00
|
|
|
select NFS_V4_2_SSC_HELPER if NFS_V4_2
|
2009-01-22 08:08:58 +00:00
|
|
|
help
|
|
|
|
|
This option enables support in your system's NFS server for
|
|
|
|
|
version 4 of the NFS protocol (RFC 3530).
|
|
|
|
|
|
|
|
|
|
To export files using NFSv4, you need to install additional user
|
|
|
|
|
space programs which can be found in the Linux nfs-utils package,
|
|
|
|
|
available from http://linux-nfs.org/.
|
|
|
|
|
|
|
|
|
|
If unsure, say N.
|
2011-11-01 17:35:21 +00:00
|
|
|
|
nfsd: implement pNFS operations
Add support for the GETDEVICEINFO, LAYOUTGET, LAYOUTCOMMIT and
LAYOUTRETURN NFSv4.1 operations, as well as backing code to manage
outstanding layouts and devices.
Layout management is very straight forward, with a nfs4_layout_stateid
structure that extends nfs4_stid to manage layout stateids as the
top-level structure. It is linked into the nfs4_file and nfs4_client
structures like the other stateids, and contains a linked list of
layouts that hang of the stateid. The actual layout operations are
implemented in layout drivers that are not part of this commit, but
will be added later.
The worst part of this commit is the management of the pNFS device IDs,
which suffers from a specification that is not sanely implementable due
to the fact that the device-IDs are global and not bound to an export,
and have a small enough size so that we can't store the fsid portion of
a file handle, and must never be reused. As we still do need perform all
export authentication and validation checks on a device ID passed to
GETDEVICEINFO we are caught between a rock and a hard place. To work
around this issue we add a new hash that maps from a 64-bit integer to a
fsid so that we can look up the export to authenticate against it,
a 32-bit integer as a generation that we can bump when changing the device,
and a currently unused 32-bit integer that could be used in the future
to handle more than a single device per export. Entries in this hash
table are never deleted as we can't reuse the ids anyway, and would have
a severe lifetime problem anyway as Linux export structures are temporary
structures that can go away under load.
Parts of the XDR data, structures and marshaling/unmarshaling code, as
well as many concepts are derived from the old pNFS server implementation
from Andy Adamson, Benny Halevy, Dean Hildebrand, Marc Eshel, Fred Isaman,
Mike Sager, Ricardo Labiaga and many others.
Signed-off-by: Christoph Hellwig <hch@lst.de>
2014-05-05 11:11:59 +00:00
|
|
|
config NFSD_PNFS
|
2016-03-04 19:46:16 +00:00
|
|
|
bool
|
|
|
|
|
|
|
|
|
|
config NFSD_BLOCKLAYOUT
|
|
|
|
|
bool "NFSv4.1 server support for pNFS block layouts"
|
2016-03-09 14:43:27 +00:00
|
|
|
depends on NFSD_V4 && BLOCK
|
2016-03-04 19:46:16 +00:00
|
|
|
select NFSD_PNFS
|
2016-07-08 13:53:20 +00:00
|
|
|
select EXPORTFS_BLOCK_OPS
|
nfsd: implement pNFS operations
Add support for the GETDEVICEINFO, LAYOUTGET, LAYOUTCOMMIT and
LAYOUTRETURN NFSv4.1 operations, as well as backing code to manage
outstanding layouts and devices.
Layout management is very straight forward, with a nfs4_layout_stateid
structure that extends nfs4_stid to manage layout stateids as the
top-level structure. It is linked into the nfs4_file and nfs4_client
structures like the other stateids, and contains a linked list of
layouts that hang of the stateid. The actual layout operations are
implemented in layout drivers that are not part of this commit, but
will be added later.
The worst part of this commit is the management of the pNFS device IDs,
which suffers from a specification that is not sanely implementable due
to the fact that the device-IDs are global and not bound to an export,
and have a small enough size so that we can't store the fsid portion of
a file handle, and must never be reused. As we still do need perform all
export authentication and validation checks on a device ID passed to
GETDEVICEINFO we are caught between a rock and a hard place. To work
around this issue we add a new hash that maps from a 64-bit integer to a
fsid so that we can look up the export to authenticate against it,
a 32-bit integer as a generation that we can bump when changing the device,
and a currently unused 32-bit integer that could be used in the future
to handle more than a single device per export. Entries in this hash
table are never deleted as we can't reuse the ids anyway, and would have
a severe lifetime problem anyway as Linux export structures are temporary
structures that can go away under load.
Parts of the XDR data, structures and marshaling/unmarshaling code, as
well as many concepts are derived from the old pNFS server implementation
from Andy Adamson, Benny Halevy, Dean Hildebrand, Marc Eshel, Fred Isaman,
Mike Sager, Ricardo Labiaga and many others.
Signed-off-by: Christoph Hellwig <hch@lst.de>
2014-05-05 11:11:59 +00:00
|
|
|
help
|
2016-03-04 19:46:16 +00:00
|
|
|
This option enables support for the exporting pNFS block layouts
|
|
|
|
|
in the kernel's NFS server. The pNFS block layout enables NFS
|
2021-03-18 20:22:21 +00:00
|
|
|
clients to directly perform I/O to block devices accessible to both
|
2016-03-04 19:46:16 +00:00
|
|
|
the server and the clients. See RFC 5663 for more details.
|
nfsd: implement pNFS operations
Add support for the GETDEVICEINFO, LAYOUTGET, LAYOUTCOMMIT and
LAYOUTRETURN NFSv4.1 operations, as well as backing code to manage
outstanding layouts and devices.
Layout management is very straight forward, with a nfs4_layout_stateid
structure that extends nfs4_stid to manage layout stateids as the
top-level structure. It is linked into the nfs4_file and nfs4_client
structures like the other stateids, and contains a linked list of
layouts that hang of the stateid. The actual layout operations are
implemented in layout drivers that are not part of this commit, but
will be added later.
The worst part of this commit is the management of the pNFS device IDs,
which suffers from a specification that is not sanely implementable due
to the fact that the device-IDs are global and not bound to an export,
and have a small enough size so that we can't store the fsid portion of
a file handle, and must never be reused. As we still do need perform all
export authentication and validation checks on a device ID passed to
GETDEVICEINFO we are caught between a rock and a hard place. To work
around this issue we add a new hash that maps from a 64-bit integer to a
fsid so that we can look up the export to authenticate against it,
a 32-bit integer as a generation that we can bump when changing the device,
and a currently unused 32-bit integer that could be used in the future
to handle more than a single device per export. Entries in this hash
table are never deleted as we can't reuse the ids anyway, and would have
a severe lifetime problem anyway as Linux export structures are temporary
structures that can go away under load.
Parts of the XDR data, structures and marshaling/unmarshaling code, as
well as many concepts are derived from the old pNFS server implementation
from Andy Adamson, Benny Halevy, Dean Hildebrand, Marc Eshel, Fred Isaman,
Mike Sager, Ricardo Labiaga and many others.
Signed-off-by: Christoph Hellwig <hch@lst.de>
2014-05-05 11:11:59 +00:00
|
|
|
|
|
|
|
|
If unsure, say N.
|
|
|
|
|
|
2016-03-04 19:46:17 +00:00
|
|
|
config NFSD_SCSILAYOUT
|
|
|
|
|
bool "NFSv4.1 server support for pNFS SCSI layouts"
|
2016-03-09 14:43:27 +00:00
|
|
|
depends on NFSD_V4 && BLOCK
|
2016-03-04 19:46:17 +00:00
|
|
|
select NFSD_PNFS
|
2016-07-08 13:53:20 +00:00
|
|
|
select EXPORTFS_BLOCK_OPS
|
2016-03-04 19:46:17 +00:00
|
|
|
help
|
|
|
|
|
This option enables support for the exporting pNFS SCSI layouts
|
|
|
|
|
in the kernel's NFS server. The pNFS SCSI layout enables NFS
|
2021-03-18 20:22:21 +00:00
|
|
|
clients to directly perform I/O to SCSI devices accessible to both
|
2016-03-04 19:46:17 +00:00
|
|
|
the server and the clients. See draft-ietf-nfsv4-scsi-layout for
|
|
|
|
|
more details.
|
|
|
|
|
|
|
|
|
|
If unsure, say N.
|
|
|
|
|
|
2016-06-14 20:41:28 +00:00
|
|
|
config NFSD_FLEXFILELAYOUT
|
|
|
|
|
bool "NFSv4.1 server support for pNFS Flex File layouts"
|
|
|
|
|
depends on NFSD_V4
|
|
|
|
|
select NFSD_PNFS
|
|
|
|
|
help
|
|
|
|
|
This option enables support for the exporting pNFS Flex File
|
|
|
|
|
layouts in the kernel's NFS server. The pNFS Flex File layout
|
|
|
|
|
enables NFS clients to directly perform I/O to NFSv3 devices
|
2021-03-18 20:22:21 +00:00
|
|
|
accessible to both the server and the clients. See
|
2016-06-14 20:41:28 +00:00
|
|
|
draft-ietf-nfsv4-flex-files for more details.
|
|
|
|
|
|
|
|
|
|
Warning, this server implements the bare minimum functionality
|
|
|
|
|
to be a flex file server - it is for testing the client,
|
|
|
|
|
not for use in production.
|
|
|
|
|
|
|
|
|
|
If unsure, say N.
|
|
|
|
|
|
2019-10-07 14:56:48 +00:00
|
|
|
config NFSD_V4_2_INTER_SSC
|
|
|
|
|
bool "NFSv4.2 inter server to server COPY"
|
2021-04-22 07:37:49 +00:00
|
|
|
depends on NFSD_V4 && NFS_V4_2
|
2019-10-07 14:56:48 +00:00
|
|
|
help
|
|
|
|
|
This option enables support for NFSv4.2 inter server to
|
|
|
|
|
server copy where the destination server calls the NFSv4.2
|
|
|
|
|
client to read the data to copy from the source server.
|
|
|
|
|
|
|
|
|
|
If unsure, say N.
|
|
|
|
|
|
2013-05-02 17:19:10 +00:00
|
|
|
config NFSD_V4_SECURITY_LABEL
|
|
|
|
|
bool "Provide Security Label support for NFSv4 server"
|
|
|
|
|
depends on NFSD_V4 && SECURITY
|
|
|
|
|
help
|
|
|
|
|
|
|
|
|
|
Say Y here if you want enable fine-grained security label attribute
|
|
|
|
|
support for NFS version 4. Security labels allow security modules like
|
|
|
|
|
SELinux and Smack to label files to facilitate enforcement of their policies.
|
|
|
|
|
Without this an NFSv4 mount will have the same label on each file.
|
|
|
|
|
|
|
|
|
|
If you do not wish to enable fine-grained security labels SELinux or
|
|
|
|
|
Smack policies on NFSv4 files, say N.
|
