34 lines
1.6 KiB
Text
34 lines
1.6 KiB
Text
# To configure sfsrwsd (part of the SFS server subsystem), copy this file
|
|
# (sfsrwsd_config.sample) to sfsrwsd_config and edit as necessary.
|
|
#
|
|
# Normally, it should not be necessary for you to specify Hostname
|
|
# or Keyfile options, only Export statements.
|
|
#
|
|
# Configuration reference:
|
|
#
|
|
# Hostname name
|
|
# Set the Location part of the server's self-certifying pathname. The
|
|
# default is the current host's fully-qualified hostname.
|
|
#
|
|
# Keyfile path
|
|
# Tells sfsrwsd to look for its private key in file path. The default
|
|
# is sfs_host_key. SFS looks for file names that do not start with /
|
|
# in /etc/sfs, or whatever directory you specified if you used the
|
|
# --with-etcdir option to configure (see configure).
|
|
#
|
|
# Export local-directory sfs-name [R|W]
|
|
# Tells sfsrwsd to export local-directory, giving it the name sfs-name
|
|
# with respect to the server's self-certifying pathname. Appending R
|
|
# to an export directive gives anonymous users read-only access to
|
|
# the file system (under user ID -2 and group ID -2). Appending W
|
|
# gives anonymous users both read and write access. See Quick server
|
|
# setup, for an example of the Export directive. There is almost no
|
|
# reason to use the W flag. The R flag lets anyone on the Internet
|
|
# issue NFS calls to your kernel as user -2. SFS filters these calls;
|
|
# it makes sure that they operate on files covered by the export
|
|
# directive, and it blocks any calls that would modify the file system.
|
|
# This approach is safe given a perfect NFS3 implementation. If,
|
|
# however, there are bugs in your NFS code, attackers may exploit
|
|
# them if you have the R option--probably just crashing your server
|
|
# but possibly doing worse
|
|
|