History log of /src/sys/kern/vfs_export.c (Results 1 – 25 of 1248)
Revision Date Author Comments
# f61c48f4 01-Aug-2025 Kyle Evans <kevans@FreeBSD.org>

kern: rename crsetgroups_fallback, document it in ucred(9)

As of FreeBSD 15.0, crsetgroups() *only* sets supplementary groups,
while crsetgroups_and_egid() will do both using an array of the same
st

kern: rename crsetgroups_fallback, document it in ucred(9)

As of FreeBSD 15.0, crsetgroups() *only* sets supplementary groups,
while crsetgroups_and_egid() will do both using an array of the same
style that previous versions used for crsetgroups() -- i.e., the first
element is the egid, and the remainder are supplementary groups.

Unlike the previous iteration of crsetgroups(), crsetgroups_and_egid()
is less prone to misuse as the caller must provide a default egid to use
in case the array is empty. This is particularly useful for groups
being set from data provided by userland.

Reviewed by: olce
Suggested by: olce
Differential Revision: https://reviews.freebsd.org/D51647

show more ...


# 5169d430 03-Nov-2024 Olivier Certner <olce@FreeBSD.org>

nfs: Fallback to GID_NOGROUP on no groups

We cannot unconditionally access nfsd's VNET variables in
'sys/kern/vfs_export.c' nor 'sys/fs/nfsserver/nfs_nfsdsubs.c', as they
may not have been compiled

nfs: Fallback to GID_NOGROUP on no groups

We cannot unconditionally access nfsd's VNET variables in
'sys/kern/vfs_export.c' nor 'sys/fs/nfsserver/nfs_nfsdsubs.c', as they
may not have been compiled in depending on build options.

So, forget about the extra mile of using the configured default group
and use the hardcoded GID_NOGROUP (which differs only on systems running
nfsuserd(8) and with a non-default GID for their "nogroup" group).

Reported by: rpokala, bapt (MINIMAL compile breakup)
Reported by: cy, David Wolfskill (panics caused by mountd(8))
Approved by: markj (mentor)
Fixes: cfbe7a62dc62 ("nfs, rpc: Ensure kernel credentials have at least one group")

show more ...


# cfbe7a62 02-Oct-2024 Olivier Certner <olce@FreeBSD.org>

nfs, rpc: Ensure kernel credentials have at least one group

This fixes several bugs where some 'struct ucred' in the kernel,
constructed from user input (via nmount(2)) or obtained from other
server

nfs, rpc: Ensure kernel credentials have at least one group

This fixes several bugs where some 'struct ucred' in the kernel,
constructed from user input (via nmount(2)) or obtained from other
servers (e.g., gssd(8)), could have an unfilled 'cr_groups' field and
whose 'cr_groups[0]' (or 'cr_gid', which is an alias) was later
accessed, causing an uninitialized access giving random access rights.

Use crsetgroups_fallback() to enforce a fallback group when possible.
For NFS, the chosen fallback group is that of the NFS server in the
current VNET (NFSD_VNET(nfsrv_defaultgid)).

There does not seem to be any sensible fallback available in rpc code
(sys/rpc/svc_auth.c, svc_getcred()) on AUTH_UNIX (TLS or not), so just
fail credential retrieval there. Stock NSS sources, rpc.tlsservd(8) or
rpc.tlsclntd(8) provide non-empty group lists, so will not be impacted.

Discussed with: rmacklem (by mail)
Approved by: markj (mentor)
MFC after: 3 days
Differential Revision: https://reviews.freebsd.org/D46918

show more ...


# 29363fb4 23-Nov-2023 Warner Losh <imp@FreeBSD.org>

sys: Remove ancient SCCS tags.

Remove ancient SCCS tags from the tree, automated scripting, with two
minor fixup to keep things compiling. All the common forms in the tree
were removed with a perl s

sys: Remove ancient SCCS tags.

Remove ancient SCCS tags from the tree, automated scripting, with two
minor fixup to keep things compiling. All the common forms in the tree
were removed with a perl script.

Sponsored by: Netflix

show more ...


# 685dc743 16-Aug-2023 Warner Losh <imp@FreeBSD.org>

sys: Remove $FreeBSD$: one-line .c pattern

Remove /^[\s*]*__FBSDID\("\$FreeBSD\$"\);?\s*\n/


# 88175af8 21-Feb-2023 Rick Macklem <rmacklem@FreeBSD.org>

vfs_export: Add mnt_exjail to control exports done in prisons

If there are multiple instances of mountd(8) (in different
prisons), there will be confusion if they manipulate the
exports of the same

vfs_export: Add mnt_exjail to control exports done in prisons

If there are multiple instances of mountd(8) (in different
prisons), there will be confusion if they manipulate the
exports of the same file system. This patch adds mnt_exjail
to "struct mount" so that the credentials (and, therefore,
the prison) that did the exports for that file system can
be recorded. If another prison has already exported the
file system, vfs_export() will fail with an error.
If mnt_exjail == NULL, the file system has not been exported.
mnt_exjail is checked by the NFS server, so that exports done
from within a different prison will not be used.

The patch also implements vfs_exjail_destroy(), which is
called from prison_cleanup() to release all the mnt_exjail
credential references, so that the prison can be removed.
Mainly to avoid doing a scan of the mountlist for the case
where there were no exports done from within the prison,
a count of how many file systems have been exported from
within the prison is kept in pr_exportcnt.

Reviewed by: markj
Discussed with: jamie
Differential Revision: https://reviews.freebsd.org/D38371
MFC after: 3 months

show more ...


# db565512 04-Feb-2023 Rick Macklem <rmacklem@FreeBSD.org>

vfs_mount.c: Free exports structures in vfs_destroy_mount()

During testing of exporting file systems in jails, I
noticed that the export structures on a mount
were not being free'd when the mount is

vfs_mount.c: Free exports structures in vfs_destroy_mount()

During testing of exporting file systems in jails, I
noticed that the export structures on a mount
were not being free'd when the mount is dismounted.

This bug appears to have been in the system for a
very long time. It would have resulted in a slow memory
leak when exported file systems were dismounted.

Prior to r362158, freeing the structures during dismount
would not have been safe, since VFS_CHECKEXP() returned
a pointer into an export structure, which might still have been
used by the NFS server for an in-progress RPC when the file system
is dismounted. r362158 fixed this, so it should now be safe
to free the structures in vfs_mount_destroy(), which is what
this patch does.

Reviewed by: kib
MFC after: 1 month
Differential Revision: https://reviews.freebsd.org/D38385

show more ...


# d94e0bdc 04-Feb-2023 Rick Macklem <rmacklem@FreeBSD.org>

Revert "vfs_export: Add checks for correct prison when updating exports"

This reverts commit 7926a01ed7ae7cefd81ef4cc2142c35b84d81913.

A new patch in D38371 is being considered for doing this.


# 7926a01e 03-Feb-2023 Rick Macklem <rmacklem@FreeBSD.org>

vfs_export: Add checks for correct prison when updating exports

mountd(8) basically does the following:
getmntinfo()
for each mount
delete_exports
using nmount(2) to do the creation/deletion o

vfs_export: Add checks for correct prison when updating exports

mountd(8) basically does the following:
getmntinfo()
for each mount
delete_exports
using nmount(2) to do the creation/deletion of individual exports.

For prison0 (and for other prisons if enforce_statfs == 0) getmntinfo()
returns all mount points, including ones being used within other prisons.
This can cause confusion if the same file system is specified in the
exports(5) file for multiple prisons.

This patch adds a perminent identifier to each prison
and marks which prison did the exports in a field of
the mount structure called mnt_exjail. This field can
then be compared to the perminent identifier for the
prison that the thread's credentials is in.
Also required was a new function called prison_isalive_permid()
which returns if the prison is alive, so that the check can be
ignored for prisons that have been removed.

This prepares the system to allow mountd(8) to run in multiple
prisons, including prison0.

Future commits will complete the modifications to allow mountd(8)
to run in vnet prisons. Until then, these changes should not affect
semantics.

Reviewed by: markj
MFC after: 3 months
Differential Revision: https://reviews.freebsd.org/D38144

show more ...


# 6fed89b1 01-Sep-2020 Mateusz Guzik <mjg@FreeBSD.org>

kern: clean up empty lines in .c and .h files


# 422f38d8 10-Jul-2020 Mateusz Guzik <mjg@FreeBSD.org>

vfs: fix trivial whitespace issues which don't interefere with blame

.. even without the -w switch


# 33b39b66 16-Jun-2020 Ryan Moeller <freqlabs@FreeBSD.org>

Apply default security flavor in vfs_export

There may be some version of mountd out there that does not supply a default
security flavor when none is given for an export.

Set the default security f

Apply default security flavor in vfs_export

There may be some version of mountd out there that does not supply a default
security flavor when none is given for an export.

Set the default security flavor in vfs_export if none is given, and remove the
workaround for oexport compat.

Reported by: npn
Reviewed by: rmacklem
Approved by: mav (mentor)
MFC after: 3 days
Sponsored by: iXsystems, Inc.
Differential Revision: https://reviews.freebsd.org/D25300

show more ...


# 1f7104d7 14-Jun-2020 Rick Macklem <rmacklem@FreeBSD.org>

Fix export_args ex_flags field so that is 64bits, the same as mnt_flags.

Since mnt_flags was upgraded to 64bits there has been a quirk in
"struct export_args", since it hold a copy of mnt_flags
in e

Fix export_args ex_flags field so that is 64bits, the same as mnt_flags.

Since mnt_flags was upgraded to 64bits there has been a quirk in
"struct export_args", since it hold a copy of mnt_flags
in ex_flags, which is an "int" (32bits).
This happens to currently work, since all the flag bits used in ex_flags are
defined in the low order 32bits. However, new export flags cannot be defined.
Also, ex_anon is a "struct xucred", which limits it to 16 additional groups.
This patch revises "struct export_args" to make ex_flags 64bits and replaces
ex_anon with ex_uid, ex_ngroups and ex_groups (which points to a
groups list, so it can be malloc'd up to NGROUPS in size.
This requires that the VFS_CHECKEXP() arguments change, so I also modified the
last "secflavors" argument to be an array pointer, so that the
secflavors could be copied in VFS_CHECKEXP() while the export entry is locked.
(Without this patch VFS_CHECKEXP() returns a pointer to the secflavors
array and then it is used after being unlocked, which is potentially
a problem if the exports entry is changed.
In practice this does not occur when mountd is run with "-S",
but I think it is worth fixing.)

This patch also deleted the vfs_oexport_conv() function, since
do_mount_update() does the conversion, as required by the old vfs_cmount()
calls.

Reviewed by: kib, freqlabs
Relnotes: yes
Differential Revision: https://reviews.freebsd.org/D25088

show more ...


# e51e957e 11-May-2020 Ryan Moeller <freqlabs@FreeBSD.org>

vfs_exports: Tighten bounds and assert consistency of numsecflavors

We know the value must be greater than 0 and less than MAXSECFLAVORS.

Reject values outside this range in the initial check in vf

vfs_exports: Tighten bounds and assert consistency of numsecflavors

We know the value must be greater than 0 and less than MAXSECFLAVORS.

Reject values outside this range in the initial check in vfs_export and add KASSERTs
in the later consumers.

Also check that we are called with one of either MNT_DELEXPORT or MNT_EXPORTED set.

Reviewed by: rmacklem
Approved by: mav (mentor)
MFC after: 1 week
Sponsored by: iXsystems, Inc.
Differential Revision: https://reviews.freebsd.org/D24753

show more ...


# 3d5db455 24-Nov-2018 Dimitry Andric <dim@FreeBSD.org>

Merge ^/head r340427 through r340868.


# 6d2e2df7 23-Nov-2018 Mark Johnston <markj@FreeBSD.org>

Ensure that directory entry padding bytes are zeroed.

Directory entries must be padded to maintain alignment; in many
filesystems the padding was not initialized, resulting in stack
memory being cop

Ensure that directory entry padding bytes are zeroed.

Directory entries must be padded to maintain alignment; in many
filesystems the padding was not initialized, resulting in stack
memory being copied out to userspace. With the ino64 work there
are also some explicit pad fields in struct dirent. Add a subroutine
to clear these bytes and use it in the in-tree filesystems. The
NFS client is omitted for now as it was fixed separately in r340787.

Reported by: Thomas Barabosch, Fraunhofer FKIE
Reviewed by: kib
MFC after: 3 days
Sponsored by: The FreeBSD Foundation

show more ...


# f61c48f4 01-Aug-2025 Kyle Evans <kevans@FreeBSD.org>

kern: rename crsetgroups_fallback, document it in ucred(9)

As of FreeBSD 15.0, crsetgroups() *only* sets supplementary groups,
while crsetgroups_and_egid() will do both using an array of the same
st

kern: rename crsetgroups_fallback, document it in ucred(9)

As of FreeBSD 15.0, crsetgroups() *only* sets supplementary groups,
while crsetgroups_and_egid() will do both using an array of the same
style that previous versions used for crsetgroups() -- i.e., the first
element is the egid, and the remainder are supplementary groups.

Unlike the previous iteration of crsetgroups(), crsetgroups_and_egid()
is less prone to misuse as the caller must provide a default egid to use
in case the array is empty. This is particularly useful for groups
being set from data provided by userland.

Reviewed by: olce
Suggested by: olce
Differential Revision: https://reviews.freebsd.org/D51647

show more ...


# 5169d430 03-Nov-2024 Olivier Certner <olce@FreeBSD.org>

nfs: Fallback to GID_NOGROUP on no groups

We cannot unconditionally access nfsd's VNET variables in
'sys/kern/vfs_export.c' nor 'sys/fs/nfsserver/nfs_nfsdsubs.c', as they
may not have been compiled

nfs: Fallback to GID_NOGROUP on no groups

We cannot unconditionally access nfsd's VNET variables in
'sys/kern/vfs_export.c' nor 'sys/fs/nfsserver/nfs_nfsdsubs.c', as they
may not have been compiled in depending on build options.

So, forget about the extra mile of using the configured default group
and use the hardcoded GID_NOGROUP (which differs only on systems running
nfsuserd(8) and with a non-default GID for their "nogroup" group).

Reported by: rpokala, bapt (MINIMAL compile breakup)
Reported by: cy, David Wolfskill (panics caused by mountd(8))
Approved by: markj (mentor)
Fixes: cfbe7a62dc62 ("nfs, rpc: Ensure kernel credentials have at least one group")

show more ...


# cfbe7a62 02-Oct-2024 Olivier Certner <olce@FreeBSD.org>

nfs, rpc: Ensure kernel credentials have at least one group

This fixes several bugs where some 'struct ucred' in the kernel,
constructed from user input (via nmount(2)) or obtained from other
server

nfs, rpc: Ensure kernel credentials have at least one group

This fixes several bugs where some 'struct ucred' in the kernel,
constructed from user input (via nmount(2)) or obtained from other
servers (e.g., gssd(8)), could have an unfilled 'cr_groups' field and
whose 'cr_groups[0]' (or 'cr_gid', which is an alias) was later
accessed, causing an uninitialized access giving random access rights.

Use crsetgroups_fallback() to enforce a fallback group when possible.
For NFS, the chosen fallback group is that of the NFS server in the
current VNET (NFSD_VNET(nfsrv_defaultgid)).

There does not seem to be any sensible fallback available in rpc code
(sys/rpc/svc_auth.c, svc_getcred()) on AUTH_UNIX (TLS or not), so just
fail credential retrieval there. Stock NSS sources, rpc.tlsservd(8) or
rpc.tlsclntd(8) provide non-empty group lists, so will not be impacted.

Discussed with: rmacklem (by mail)
Approved by: markj (mentor)
MFC after: 3 days
Differential Revision: https://reviews.freebsd.org/D46918

show more ...


# 29363fb4 23-Nov-2023 Warner Losh <imp@FreeBSD.org>

sys: Remove ancient SCCS tags.

Remove ancient SCCS tags from the tree, automated scripting, with two
minor fixup to keep things compiling. All the common forms in the tree
were removed with a perl s

sys: Remove ancient SCCS tags.

Remove ancient SCCS tags from the tree, automated scripting, with two
minor fixup to keep things compiling. All the common forms in the tree
were removed with a perl script.

Sponsored by: Netflix

show more ...


# 685dc743 16-Aug-2023 Warner Losh <imp@FreeBSD.org>

sys: Remove $FreeBSD$: one-line .c pattern

Remove /^[\s*]*__FBSDID\("\$FreeBSD\$"\);?\s*\n/


# 88175af8 21-Feb-2023 Rick Macklem <rmacklem@FreeBSD.org>

vfs_export: Add mnt_exjail to control exports done in prisons

If there are multiple instances of mountd(8) (in different
prisons), there will be confusion if they manipulate the
exports of the same

vfs_export: Add mnt_exjail to control exports done in prisons

If there are multiple instances of mountd(8) (in different
prisons), there will be confusion if they manipulate the
exports of the same file system. This patch adds mnt_exjail
to "struct mount" so that the credentials (and, therefore,
the prison) that did the exports for that file system can
be recorded. If another prison has already exported the
file system, vfs_export() will fail with an error.
If mnt_exjail == NULL, the file system has not been exported.
mnt_exjail is checked by the NFS server, so that exports done
from within a different prison will not be used.

The patch also implements vfs_exjail_destroy(), which is
called from prison_cleanup() to release all the mnt_exjail
credential references, so that the prison can be removed.
Mainly to avoid doing a scan of the mountlist for the case
where there were no exports done from within the prison,
a count of how many file systems have been exported from
within the prison is kept in pr_exportcnt.

Reviewed by: markj
Discussed with: jamie
Differential Revision: https://reviews.freebsd.org/D38371
MFC after: 3 months

show more ...


# db565512 04-Feb-2023 Rick Macklem <rmacklem@FreeBSD.org>

vfs_mount.c: Free exports structures in vfs_destroy_mount()

During testing of exporting file systems in jails, I
noticed that the export structures on a mount
were not being free'd when the mount is

vfs_mount.c: Free exports structures in vfs_destroy_mount()

During testing of exporting file systems in jails, I
noticed that the export structures on a mount
were not being free'd when the mount is dismounted.

This bug appears to have been in the system for a
very long time. It would have resulted in a slow memory
leak when exported file systems were dismounted.

Prior to r362158, freeing the structures during dismount
would not have been safe, since VFS_CHECKEXP() returned
a pointer into an export structure, which might still have been
used by the NFS server for an in-progress RPC when the file system
is dismounted. r362158 fixed this, so it should now be safe
to free the structures in vfs_mount_destroy(), which is what
this patch does.

Reviewed by: kib
MFC after: 1 month
Differential Revision: https://reviews.freebsd.org/D38385

show more ...


# d94e0bdc 04-Feb-2023 Rick Macklem <rmacklem@FreeBSD.org>

Revert "vfs_export: Add checks for correct prison when updating exports"

This reverts commit 7926a01ed7ae7cefd81ef4cc2142c35b84d81913.

A new patch in D38371 is being considered for doing this.


# 7926a01e 03-Feb-2023 Rick Macklem <rmacklem@FreeBSD.org>

vfs_export: Add checks for correct prison when updating exports

mountd(8) basically does the following:
getmntinfo()
for each mount
delete_exports
using nmount(2) to do the creation/deletion o

vfs_export: Add checks for correct prison when updating exports

mountd(8) basically does the following:
getmntinfo()
for each mount
delete_exports
using nmount(2) to do the creation/deletion of individual exports.

For prison0 (and for other prisons if enforce_statfs == 0) getmntinfo()
returns all mount points, including ones being used within other prisons.
This can cause confusion if the same file system is specified in the
exports(5) file for multiple prisons.

This patch adds a perminent identifier to each prison
and marks which prison did the exports in a field of
the mount structure called mnt_exjail. This field can
then be compared to the perminent identifier for the
prison that the thread's credentials is in.
Also required was a new function called prison_isalive_permid()
which returns if the prison is alive, so that the check can be
ignored for prisons that have been removed.

This prepares the system to allow mountd(8) to run in multiple
prisons, including prison0.

Future commits will complete the modifications to allow mountd(8)
to run in vnet prisons. Until then, these changes should not affect
semantics.

Reviewed by: markj
MFC after: 3 months
Differential Revision: https://reviews.freebsd.org/D38144

show more ...


12345678910>>...50