| Commit message (Collapse) | Author | Age | Files | Lines |
|
|
|
|
|
|
|
|
|
|
|
| |
When a re-exporting NFS server reboots, none of the subvolumes are present.
This is because the NFS client code will mount only upon first access.
So, when we see an NFS handle with an yet unknown fsidnum, lookup in
the reexport database for it.
If one is found, stat the path to trigger the mount.
That way stale NFS handles are avoided after a reboot.
Signed-off-by: Richard Weinberger <richard@nod.at>
Signed-off-by: Steve Dickson <steved@redhat.com>
|
|
|
|
|
|
|
|
|
| |
Detect the case when a NFS share is re-exported and assign an
fsidnum to it.
The fsidnum is read (or created) from the reexport database.
Signed-off-by: Richard Weinberger <richard@nod.at>
Signed-off-by: Steve Dickson <steved@redhat.com>
|
|
|
|
|
|
|
|
|
|
|
| |
The overall goal is to enable administrators to require the use of
transport layer security when clients access particular exports.
This patch adds support to exportfs to parse, display, and push
into the kernel a new xprtsec= export option.
Signed-off-by: Chuck Lever <chuck.lever@oracle.com>
Signed-off-by: Steve Dickson <steved@redhat.com>
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Currently the following setup causes failure:
1. /etc/exports:
/ *(rw,crossmnt,no_subtree_check,fsid=root)
2. /etc/nfs.conf:
[exports]
rootdir=/nfs_srv
3. Mounts:
/root/fs1.ext4 on /nfs_srv type ext4 (rw,relatime)
/root/fs2.ext4 on /nfs_srv/fs2 type ext4 (rw,relatime)
4. On the client:
$ ls /nfs_client/fs2
ls: cannot open directory '/nfs_client/fs2': Stale file handle
The problem is that next_mnt() misses the corner case that
every mount is a sub-mount of "/".
So it fails to see that /nfs_srv/fs2 is a mountpoint when the
client asks for fs2 it and as consequence the crossmnt mechanism
fails.
Signed-off-by: Richard Weinberger <richard@nod.at>
Signed-off-by: Steve Dickson <steved@redhat.com>
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
autoconf AC_SYS_LARGEFILE is used by configure to add needed defines
when needed for enabling 64bit off_t, therefore replacing statfs64 with
statfs should be functionally same. Additionally this helps compiling
with latest musl where 64bit LFS functions like statfs64 and friends are
now moved under _LARGEFILE64_SOURCE feature test macro, this works on
glibc systems because _GNU_SOURCE macros also enables
_LARGEFILE64_SOURCE indirectly. This is not case with musl and this
latest issue is exposed.
Signed-off-by: Khem Raj <raj.khem@gmail.com>
Signed-off-by: Steve Dickson <steved@redhat.com>
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Some filesystems cannot be exported without an fsid or uuid.
tmpfs is the main example.
When mountd (or exportd) creates nfsv4 pseudo-root exports for the path
leading down to an export point it exports each directory without any
fsid or uuid. If one of these directories is on tmpfs, that will fail.
The net result is that exporting a subdirectory of a tmpfs filesystem
will not work over NFSv4 as the parents within the filesystem cannot be
exported. It will either fail, or fall-back to NFSv3 (depending on the
version of the mount.nfs program).
To fix this we need to provide an fsid or uuid for these pseudo-root
exports. This patch does that by creating an RFC-4122 V5 compatible
UUID based on an arbitrary seed and the path to the export.
To check if an export needs a uuid, text_export() is moved from exportfs
to libexport.a, modified slightly and renamed to export_test().
Reported-by: Petr Vorel <pvorel@suse.cz>
Reviewed-by: Petr Vorel <pvorel@suse.cz>
Tested-by: Petr Vorel <pvorel@suse.cz>
Signed-off-by: NeilBrown <neilb@suse.de>
Signed-off-by: Steve Dickson <steved@redhat.com>
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
NFSv4 does not have a MOUNT request like NFSv3 does (via the MOUNT
protocol). So these cannot be logged.
NFSv4 does have SETCLIENTID and EXCHANGE_ID. These are indirectly
visible though changes in /proc/fs/nfsd/clients.
When a new client attaches, a directory appears. When the client
detaches, through a timeout (v4.0) or DESTROY_SESSION (v4.1+)
the directory disappears.
This patch adds tracking of these changes using inotify, with log
messages when a client attaches or detaches.
Unfortuantely clients are created in two steps, the second being a
confirmation. This results in a temporary client appearing and
disappearing. It is not possible (in Linux 5.10) to detect the
unconfirmed client, so extra attach/detach messages are generated.
This patch also moves some cache* function declarations into a header
file, and makes a few related changes to #includes.
Signed-off-by: NeilBrown <neilb@suse.de>
Signed-off-by: Steve Dickson <steved@redhat.com>
|
|
|
|
|
|
|
|
|
|
|
|
| |
The DEFAULT_TTL affects the rate at which authentication messages are
logged. So it is useful to make it settable.
Add "-ttl" and "-T", and add clear statement in the documentation of
both the benefits and the possible negative effects of choosing a larger
value
Signed-off-by: NeilBrown <neil@brown.name>
Signed-off-by: Steve Dickson <steved@redhat.com>
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
When NFSv3 is used to mount a filesystem, success/failure messages are
logged by mountd and can be used for auditing. When NFSv4 is used,
there is no distinct "MOUNT" request, and nothing is logged.
We can instead log authentication requests from the kernel. These will
happen regularly - typically every 15 minutes of ongoing access - so
they may be too noisy, or might be more useful. As they might not be
wanted, make them selectable with the "AUTH" facility in xlog().
Add a "-l" to enable these logs. Alternately "debug = auth" will have
the same effect.
The same changes are made to both rpc.mountd and nfsv4.exportd.
Signed-off-by: NeilBrown <neil@brown.name>
Signed-off-by: Steve Dickson <steved@redhat.com>
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
When an "nfsd.fh" request is received from the kernel, we map the
file-handle prefix to a path name and report that (as required) and then
also add "nfsd.export" information with export flags applicable to that
path.
This is not necessary and was added as a perceived optimisation.
When updating data already in the kernel, it is unlikely to help as the
kernel can be expected to ask for both details at much the same time.
With NFSv3, new information is normally added by a MOUNT rpc request, so
this is irrelevant.
With NFSv4, the kernel requests the "nfsd.export" information when
walking down from ROOT, *before* requesting the nfsd.fh information, so
this "optimisation" causes unnecessary work.
A future patch will add logging of authentication requests, and this
double-handling would result in extra unnecessary log messages.
As this "optimisation" appears to have no practical value and some
(small) cost, let's remove it.
Signed-off-by: NeilBrown <neil@brown.name>
Signed-off-by: Steve Dickson <steved@redhat.com>
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
When use_ipaddr is not in effect, an auth_unix_ip lookup
request from the kernel for an unknown client will be
rejected. When it IS in effect, these requests are
always granted with the IP address being mapped to a
string form of the address, preceded by a '$'.
This is inconsistent behaviour and could present a small
information leak. It means that, for example, a SETCLIENT
NFSv4 request may or may not succeed depending on an
internal setting in rpc.mountd.
This is easily rectified by always checking if the
client is known.
Signed-off-by: NeilBrown <neil@brown.name>
Signed-off-by: Steve Dickson <steved@redhat.com>
|
|
Move the cache management code into libexport.a
so both mountd and exportd can use it.
Introduce cache_proccess_loop() which will
be used by exportd, instead of my_svc_run().
Signed-off-by: Steve Dickson <steved@redhat.com>
|