Page MenuHomeFreeBSD
Differential D41431

Add mac_grantbylabel
ClosedPublic
Actions

Authored by sjg on Aug 11 2023, 10:02 PM.
Tags
None
Referenced Files
Unknown Object (File)
Tue, Mar 25, 2:35 AM
Unknown Object (File)
Sat, Mar 22, 10:19 PM
Unknown Object (File)
Thu, Mar 20, 5:37 AM
Unknown Object (File)
Mon, Mar 17, 12:09 PM
Unknown Object (File)
Tue, Mar 11, 3:00 AM
Unknown Object (File)
Sun, Mar 9, 9:25 AM
Unknown Object (File)
Wed, Feb 26, 4:42 PM
Unknown Object (File)
Feb 21 2025, 6:28 PM
View All Files
Subscribers
dab
imp
jonathan

Details

Reviewers
stevek
rwatson
Commits
rG1554ba03b651: Add mac_grantbylabel
Summary

This module allows controlled privilege escallation via mac labels
securely associated with a process via mac_veriexec.

There are over 700 PRIV_* but we can compress many of them into
a single GBL_* thus constraining the size of gbl labels.

The goal is to allow a daemon to run as an unprivileged process while
still being able a set of privileged operations needed.

We add APIs to libveriexec so that userland processes can check labels
and an exec_script API that allows a suitably labeled process to run
something like a python interpreter directly if necessary;
overcomming the 'indirect' flag applied to the interpreter.

Diff Detail

Repository
rG FreeBSD src repository
Lint
Lint Skipped
Unit
Tests Skipped
Build Status
Buildable 53128
Build 50019: arc lint + arc unit

Event Timeline

sjg created this revision.Aug 11 2023, 10:02 PM
Herald added subscribers: dab, jonathan, imp. · View Herald TranscriptAug 11 2023, 10:02 PM
sjg requested review of this revision.Aug 11 2023, 10:02 PM
Harbormaster completed remote builds in B53054: Diff 125891.Aug 11 2023, 10:02 PM
sjg updated this revision to Diff 125892.Aug 11 2023, 11:42 PM

Missed two files

Harbormaster completed remote builds in B53055: Diff 125892.Aug 11 2023, 11:43 PM
sjg updated this revision to Diff 125893.Aug 11 2023, 11:46 PM

Use SPDX

Harbormaster completed remote builds in B53056: Diff 125893.Aug 11 2023, 11:46 PM
sjg updated this revision to Diff 125894.Aug 12 2023, 1:22 AM

Use correct MAC_VERIEXEC_VERSION in MODULE_DEPEND

Harbormaster completed remote builds in B53057: Diff 125894.Aug 12 2023, 1:23 AM
sjg mentioned this in D36506: veriexec: add syscall to retrieve veriexec label.Aug 14 2023, 7:28 PM
sjg updated this revision to Diff 125995.Aug 14 2023, 8:20 PM

Add veriexec_get_{path,pid}_label

Harbormaster completed remote builds in B53099: Diff 125995.Aug 14 2023, 8:21 PM
sjg updated this revision to Diff 126063.Aug 16 2023, 2:34 AM

Add -l option to veriexec

Harbormaster completed remote builds in B53128: Diff 126063.Aug 16 2023, 2:34 AM
sjg updated this revision to Diff 126097.Aug 16 2023, 10:18 PM

Update copyright year

Harbormaster completed remote builds in B53139: Diff 126097.Aug 16 2023, 10:18 PM
stevek added inline comments.Aug 16 2023, 10:31 PM
sys/security/mac_grantbylabel/mac_grantbylabel.c
59

This sysctl and variable used by it should be under #ifdef MAC_DEBUG since the MAC_GRANTBYLABEL_DBG is only filled out when MAC_DEBUG is defined.

65

This line looks like it ran a bit long?

500

Either drop this bit entirely and use MPC_LOADTIME_FLAG_NOTLATE or add MAC_GRANTBYLABEL_DEBUG to the "options"

sjg updated this revision to Diff 126106.Aug 17 2023, 1:47 AM

Cleanup per feedback

Harbormaster completed remote builds in B53146: Diff 126106.Aug 17 2023, 1:47 AM
sjg updated this revision to Diff 126132.Aug 17 2023, 3:46 PM

Update more copyright years

Harbormaster completed remote builds in B53154: Diff 126132.Aug 17 2023, 3:46 PM
sjg updated this revision to Diff 126134.Aug 17 2023, 4:41 PM

rebase and remove $FreeBSD$

Harbormaster completed remote builds in B53156: Diff 126134.Aug 17 2023, 4:41 PM
sjg marked 3 inline comments as done.Aug 17 2023, 4:45 PM

If someone could explain the rubbish about libveriexc.h being copied to mac_grantbylabel.h

stevek accepted this revision.Aug 24 2023, 7:10 PM
This revision is now accepted and ready to land.Aug 24 2023, 7:10 PM
Closed by commit rG1554ba03b651: Add mac_grantbylabel (authored by sjg). · Explain WhyAug 25 2023, 12:43 AM
This revision was automatically updated to reflect the committed changes.
sjg added a commit: rG1554ba03b651: Add mac_grantbylabel.

Revision Contents
Changeset List

PathSize
etc/
mtree/
2 lines
include/
4 lines
lib/
libveriexec/
4 lines
161 lines
127 lines
11 lines
174 lines
sbin/
veriexec/
2 lines
13 lines
56 lines
sys/
conf/
1 line
1 line
security/
mac_grantbylabel/
510 lines
sys/
security/
mac_grantbylabel/
lib/
libveriexec/
mac_grantbylabel.h
libveriexec.h
49 lines

Diff 126063

View Options

etc/mtree/BSD.include.dist

Show First 20 Lines • Show All 47 Lines • ▼ Show 20 Lines
.Fa fd .Fa fd
is a descriptor to be operated on by is a descriptor to be operated on by
.Fa cmd .Fa cmd
as described below. as described below.
Depending on the value of Depending on the value of
.Fa cmd , .Fa cmd ,
.Fn fcntl .Fn fcntl
can take an additional third argument can take an additional third argument
.Fa "long arg" . .Fa arg .
jhbUnsubmitted
Done
Inline Actions

Maybe just say the type of the 3rd arg depends on the operation (and document the type for each operation that takes the third arg) instead of trying to assume it's a single type? In CheriBSD we have a wrapper in libc to deal with this and have fcntl() as a truly var-args function. On existing platforms var-args is close enough to work for passing syscall arguments, but not all ABIs require this. (var-args are passed as a block in a bounded pointer on CHERI platforms and not just a continuation of register arguments).

jhb: Maybe just say the type of the 3rd arg depends on the operation (and document the type for each…
kibAuthorUnsubmitted
Done
Inline Actions

I pushed everything but this change, the review is updated with the man page changes.

kib: I pushed everything but this change, the review is updated with the man page changes.
Unless otherwise noted below for a specific operation,
emasteUnsubmitted
Done
Inline Actions

maybe "with type dependent on the specific operation"

or maybe

can take an additional third argument
.Fa arg.
Unless otherwise noted below for a specific operation,
.Fa arg
has type
.Vt int .
emaste: maybe "with type dependent on the specific operation" or maybe ``` can take an additional…
.Fa arg
has type
.Vt int .
.Bl -tag -width F_DUP2FD_CLOEXEC .Bl -tag -width F_DUP2FD_CLOEXEC
.It Dv F_DUPFD .It Dv F_DUPFD
Return a new descriptor as follows: Return a new descriptor as follows:
.Pp .Pp
.Bl -bullet -compact -offset 4n .Bl -bullet -compact -offset 4n
.It .It
Lowest numbered available descriptor greater than or equal to Lowest numbered available descriptor greater than or equal to
.Fa arg . .Fa arg .
▲ Show 20 Lines • Show All 121 Lines • ▼ Show 20 Lines
.It Dv F_GET_SEALS .It Dv F_GET_SEALS
Get seals associated with the file, if the underlying filesystem supports seals. Get seals associated with the file, if the underlying filesystem supports seals.
.It Dv F_ISUNIONSTACK .It Dv F_ISUNIONSTACK
Check if the vnode is part of a union stack (either the "union" flag from Check if the vnode is part of a union stack (either the "union" flag from
.Xr mount 2 .Xr mount 2
or unionfs). or unionfs).
This is a hack not intended to be used outside of libc. This is a hack not intended to be used outside of libc.
.It Dv F_KINFO .It Dv F_KINFO
Fills a Fills a
markjUnsubmitted
Done
Inline Actions
.It Dv F_KINFO
- Fills
+ Fills a
.Vt struct kinfo_file
markj:
.Vt struct kinfo_file .Vt struct kinfo_file
for the file referenced by the specified file descriptor. for the file referenced by the specified file descriptor.
The The
.Fa arg .Fa arg
argument should point to the storage for argument should point to the storage for
.Vt struct kinfo_file . .Vt struct kinfo_file .
The The
.Va kf_structsize .Va kf_structsize
▲ Show 20 Lines • Show All 78 Lines • ▼ Show 20 Lines
Seals are on a per-inode basis and require support by the underlying filesystem. Seals are on a per-inode basis and require support by the underlying filesystem.
If the underlying filesystem does not support seals, If the underlying filesystem does not support seals,
.Dv F_ADD_SEALS .Dv F_ADD_SEALS
and and
.Dv F_GET_SEALS .Dv F_GET_SEALS
will fail and return will fail and return
.Dv EINVAL . .Dv EINVAL .
.Pp .Pp
Several commands are available for doing advisory file locking; Several operations are available for doing advisory file locking;
emasteUnsubmitted
Done
Inline Actions

Is "command" or "operation" the better term, in general? I think we should be consistent between this sentence and the added text above/below

emaste: Is "command" or "operation" the better term, in general? I think we should be consistent…
they all operate on the following structure: they all operate on the following structure:
.Bd -literal .Bd -literal
struct flock { struct flock {
off_t l_start; /* starting offset */ off_t l_start; /* starting offset */
off_t l_len; /* len = 0 means until end of file */ off_t l_len; /* len = 0 means until end of file */
pid_t l_pid; /* lock owner */ pid_t l_pid; /* lock owner */
short l_type; /* lock type: read/write, etc. */ short l_type; /* lock type: read/write, etc. */
short l_whence; /* type of l_start */ short l_whence; /* type of l_start */
int l_sysid; /* remote system id or zero for local */ int l_sysid; /* remote system id or zero for local */
}; };
.Ed .Ed
These advisory file locking operations take a pointer to
emasteUnsubmitted
Done
Inline Actions

These commands take a pointer to struct flock as the third argument arg.
or
These advisory file locking commands take a pointer to struct flock as the third argument arg.

emaste: These commands take a pointer to struct flock as the third argument arg. or These advisory file…
emasteUnsubmitted
Done
Inline Actions

Maybe "operations" here too for consistency?
But from the context this one is clear so I don't mind either way.

emaste: Maybe "operations" here too for consistency? But from the context this one is clear so I don't…
.Vt struct flock
as the third argument
.Fa arg .
The commands available for advisory record locking are as follows: The commands available for advisory record locking are as follows:
.Bl -tag -width F_SETLKWX .Bl -tag -width F_SETLKWX
.It Dv F_GETLK .It Dv F_GETLK
Get the first lock that blocks the lock description pointed to by the Get the first lock that blocks the lock description pointed to by the
third argument, third argument,
.Fa arg , .Fa arg ,
taken as a pointer to a taken as a pointer to a
.Fa "struct flock" .Fa "struct flock"
▲ Show 20 Lines • Show All 477 Lines • Show Last 20 Lines
View Options

include/Makefile

Show First 20 Lines • Show All 47 Lines • ▼ Show 20 Lines
.Fa fd .Fa fd
is a descriptor to be operated on by is a descriptor to be operated on by
.Fa cmd .Fa cmd
as described below. as described below.
Depending on the value of Depending on the value of
.Fa cmd , .Fa cmd ,
.Fn fcntl .Fn fcntl
can take an additional third argument can take an additional third argument
.Fa "long arg" . .Fa arg .
jhbUnsubmitted
Done
Inline Actions

Maybe just say the type of the 3rd arg depends on the operation (and document the type for each operation that takes the third arg) instead of trying to assume it's a single type? In CheriBSD we have a wrapper in libc to deal with this and have fcntl() as a truly var-args function. On existing platforms var-args is close enough to work for passing syscall arguments, but not all ABIs require this. (var-args are passed as a block in a bounded pointer on CHERI platforms and not just a continuation of register arguments).

jhb: Maybe just say the type of the 3rd arg depends on the operation (and document the type for each…
kibAuthorUnsubmitted
Done
Inline Actions

I pushed everything but this change, the review is updated with the man page changes.

kib: I pushed everything but this change, the review is updated with the man page changes.
Unless otherwise noted below for a specific operation,
emasteUnsubmitted
Done
Inline Actions

maybe "with type dependent on the specific operation"

or maybe

can take an additional third argument
.Fa arg.
Unless otherwise noted below for a specific operation,
.Fa arg
has type
.Vt int .
emaste: maybe "with type dependent on the specific operation" or maybe ``` can take an additional…
.Fa arg
has type
.Vt int .
.Bl -tag -width F_DUP2FD_CLOEXEC .Bl -tag -width F_DUP2FD_CLOEXEC
.It Dv F_DUPFD .It Dv F_DUPFD
Return a new descriptor as follows: Return a new descriptor as follows:
.Pp .Pp
.Bl -bullet -compact -offset 4n .Bl -bullet -compact -offset 4n
.It .It
Lowest numbered available descriptor greater than or equal to Lowest numbered available descriptor greater than or equal to
.Fa arg . .Fa arg .
▲ Show 20 Lines • Show All 121 Lines • ▼ Show 20 Lines
.It Dv F_GET_SEALS .It Dv F_GET_SEALS
Get seals associated with the file, if the underlying filesystem supports seals. Get seals associated with the file, if the underlying filesystem supports seals.
.It Dv F_ISUNIONSTACK .It Dv F_ISUNIONSTACK
Check if the vnode is part of a union stack (either the "union" flag from Check if the vnode is part of a union stack (either the "union" flag from
.Xr mount 2 .Xr mount 2
or unionfs). or unionfs).
This is a hack not intended to be used outside of libc. This is a hack not intended to be used outside of libc.
.It Dv F_KINFO .It Dv F_KINFO
Fills a Fills a
markjUnsubmitted
Done
Inline Actions
.It Dv F_KINFO
- Fills
+ Fills a
.Vt struct kinfo_file
markj:
.Vt struct kinfo_file .Vt struct kinfo_file
for the file referenced by the specified file descriptor. for the file referenced by the specified file descriptor.
The The
.Fa arg .Fa arg
argument should point to the storage for argument should point to the storage for
.Vt struct kinfo_file . .Vt struct kinfo_file .
The The
.Va kf_structsize .Va kf_structsize
▲ Show 20 Lines • Show All 78 Lines • ▼ Show 20 Lines
Seals are on a per-inode basis and require support by the underlying filesystem. Seals are on a per-inode basis and require support by the underlying filesystem.
If the underlying filesystem does not support seals, If the underlying filesystem does not support seals,
.Dv F_ADD_SEALS .Dv F_ADD_SEALS
and and
.Dv F_GET_SEALS .Dv F_GET_SEALS
will fail and return will fail and return
.Dv EINVAL . .Dv EINVAL .
.Pp .Pp
Several commands are available for doing advisory file locking; Several operations are available for doing advisory file locking;
emasteUnsubmitted
Done
Inline Actions

Is "command" or "operation" the better term, in general? I think we should be consistent between this sentence and the added text above/below

emaste: Is "command" or "operation" the better term, in general? I think we should be consistent…
they all operate on the following structure: they all operate on the following structure:
.Bd -literal .Bd -literal
struct flock { struct flock {
off_t l_start; /* starting offset */ off_t l_start; /* starting offset */
off_t l_len; /* len = 0 means until end of file */ off_t l_len; /* len = 0 means until end of file */
pid_t l_pid; /* lock owner */ pid_t l_pid; /* lock owner */
short l_type; /* lock type: read/write, etc. */ short l_type; /* lock type: read/write, etc. */
short l_whence; /* type of l_start */ short l_whence; /* type of l_start */
int l_sysid; /* remote system id or zero for local */ int l_sysid; /* remote system id or zero for local */
}; };
.Ed .Ed
These advisory file locking operations take a pointer to
emasteUnsubmitted
Done
Inline Actions

These commands take a pointer to struct flock as the third argument arg.
or
These advisory file locking commands take a pointer to struct flock as the third argument arg.

emaste: These commands take a pointer to struct flock as the third argument arg. or These advisory file…
emasteUnsubmitted
Done
Inline Actions

Maybe "operations" here too for consistency?
But from the context this one is clear so I don't mind either way.

emaste: Maybe "operations" here too for consistency? But from the context this one is clear so I don't…
.Vt struct flock
as the third argument
.Fa arg .
The commands available for advisory record locking are as follows: The commands available for advisory record locking are as follows:
.Bl -tag -width F_SETLKWX .Bl -tag -width F_SETLKWX
.It Dv F_GETLK .It Dv F_GETLK
Get the first lock that blocks the lock description pointed to by the Get the first lock that blocks the lock description pointed to by the
third argument, third argument,
.Fa arg , .Fa arg ,
taken as a pointer to a taken as a pointer to a
.Fa "struct flock" .Fa "struct flock"
▲ Show 20 Lines • Show All 477 Lines • Show Last 20 Lines
View Options

lib/libveriexec/Makefile

Show First 20 Lines • Show All 47 Lines • ▼ Show 20 Lines
.Fa fd .Fa fd
is a descriptor to be operated on by is a descriptor to be operated on by
.Fa cmd .Fa cmd
as described below. as described below.
Depending on the value of Depending on the value of
.Fa cmd , .Fa cmd ,
.Fn fcntl .Fn fcntl
can take an additional third argument can take an additional third argument
.Fa "long arg" . .Fa arg .
jhbUnsubmitted
Done
Inline Actions

Maybe just say the type of the 3rd arg depends on the operation (and document the type for each operation that takes the third arg) instead of trying to assume it's a single type? In CheriBSD we have a wrapper in libc to deal with this and have fcntl() as a truly var-args function. On existing platforms var-args is close enough to work for passing syscall arguments, but not all ABIs require this. (var-args are passed as a block in a bounded pointer on CHERI platforms and not just a continuation of register arguments).

jhb: Maybe just say the type of the 3rd arg depends on the operation (and document the type for each…
kibAuthorUnsubmitted
Done
Inline Actions

I pushed everything but this change, the review is updated with the man page changes.

kib: I pushed everything but this change, the review is updated with the man page changes.
Unless otherwise noted below for a specific operation,
emasteUnsubmitted
Done
Inline Actions

maybe "with type dependent on the specific operation"

or maybe

can take an additional third argument
.Fa arg.
Unless otherwise noted below for a specific operation,
.Fa arg
has type
.Vt int .
emaste: maybe "with type dependent on the specific operation" or maybe ``` can take an additional…
.Fa arg
has type
.Vt int .
.Bl -tag -width F_DUP2FD_CLOEXEC .Bl -tag -width F_DUP2FD_CLOEXEC
.It Dv F_DUPFD .It Dv F_DUPFD
Return a new descriptor as follows: Return a new descriptor as follows:
.Pp .Pp
.Bl -bullet -compact -offset 4n .Bl -bullet -compact -offset 4n
.It .It
Lowest numbered available descriptor greater than or equal to Lowest numbered available descriptor greater than or equal to
.Fa arg . .Fa arg .
▲ Show 20 Lines • Show All 121 Lines • ▼ Show 20 Lines
.It Dv F_GET_SEALS .It Dv F_GET_SEALS
Get seals associated with the file, if the underlying filesystem supports seals. Get seals associated with the file, if the underlying filesystem supports seals.
.It Dv F_ISUNIONSTACK .It Dv F_ISUNIONSTACK
Check if the vnode is part of a union stack (either the "union" flag from Check if the vnode is part of a union stack (either the "union" flag from
.Xr mount 2 .Xr mount 2
or unionfs). or unionfs).
This is a hack not intended to be used outside of libc. This is a hack not intended to be used outside of libc.
.It Dv F_KINFO .It Dv F_KINFO
Fills a Fills a
markjUnsubmitted
Done
Inline Actions
.It Dv F_KINFO
- Fills
+ Fills a
.Vt struct kinfo_file
markj:
.Vt struct kinfo_file .Vt struct kinfo_file
for the file referenced by the specified file descriptor. for the file referenced by the specified file descriptor.
The The
.Fa arg .Fa arg
argument should point to the storage for argument should point to the storage for
.Vt struct kinfo_file . .Vt struct kinfo_file .
The The
.Va kf_structsize .Va kf_structsize
▲ Show 20 Lines • Show All 78 Lines • ▼ Show 20 Lines
Seals are on a per-inode basis and require support by the underlying filesystem. Seals are on a per-inode basis and require support by the underlying filesystem.
If the underlying filesystem does not support seals, If the underlying filesystem does not support seals,
.Dv F_ADD_SEALS .Dv F_ADD_SEALS
and and
.Dv F_GET_SEALS .Dv F_GET_SEALS
will fail and return will fail and return
.Dv EINVAL . .Dv EINVAL .
.Pp .Pp
Several commands are available for doing advisory file locking; Several operations are available for doing advisory file locking;
emasteUnsubmitted
Done
Inline Actions

Is "command" or "operation" the better term, in general? I think we should be consistent between this sentence and the added text above/below

emaste: Is "command" or "operation" the better term, in general? I think we should be consistent…
they all operate on the following structure: they all operate on the following structure:
.Bd -literal .Bd -literal
struct flock { struct flock {
off_t l_start; /* starting offset */ off_t l_start; /* starting offset */
off_t l_len; /* len = 0 means until end of file */ off_t l_len; /* len = 0 means until end of file */
pid_t l_pid; /* lock owner */ pid_t l_pid; /* lock owner */
short l_type; /* lock type: read/write, etc. */ short l_type; /* lock type: read/write, etc. */
short l_whence; /* type of l_start */ short l_whence; /* type of l_start */
int l_sysid; /* remote system id or zero for local */ int l_sysid; /* remote system id or zero for local */
}; };
.Ed .Ed
These advisory file locking operations take a pointer to
emasteUnsubmitted
Done
Inline Actions

These commands take a pointer to struct flock as the third argument arg.
or
These advisory file locking commands take a pointer to struct flock as the third argument arg.

emaste: These commands take a pointer to struct flock as the third argument arg. or These advisory file…
emasteUnsubmitted
Done
Inline Actions

Maybe "operations" here too for consistency?
But from the context this one is clear so I don't mind either way.

emaste: Maybe "operations" here too for consistency? But from the context this one is clear so I don't…
.Vt struct flock
as the third argument
.Fa arg .
The commands available for advisory record locking are as follows: The commands available for advisory record locking are as follows:
.Bl -tag -width F_SETLKWX .Bl -tag -width F_SETLKWX
.It Dv F_GETLK .It Dv F_GETLK
Get the first lock that blocks the lock description pointed to by the Get the first lock that blocks the lock description pointed to by the
third argument, third argument,
.Fa arg , .Fa arg ,
taken as a pointer to a taken as a pointer to a
.Fa "struct flock" .Fa "struct flock"
▲ Show 20 Lines • Show All 477 Lines • Show Last 20 Lines
View Options

lib/libveriexec/exec_script.c

Show First 20 Lines • Show All 47 Lines • ▼ Show 20 Lines
.Fa fd .Fa fd
is a descriptor to be operated on by is a descriptor to be operated on by
.Fa cmd .Fa cmd
as described below. as described below.
Depending on the value of Depending on the value of
.Fa cmd , .Fa cmd ,
.Fn fcntl .Fn fcntl
can take an additional third argument can take an additional third argument
.Fa "long arg" . .Fa arg .
jhbUnsubmitted
Done
Inline Actions

Maybe just say the type of the 3rd arg depends on the operation (and document the type for each operation that takes the third arg) instead of trying to assume it's a single type? In CheriBSD we have a wrapper in libc to deal with this and have fcntl() as a truly var-args function. On existing platforms var-args is close enough to work for passing syscall arguments, but not all ABIs require this. (var-args are passed as a block in a bounded pointer on CHERI platforms and not just a continuation of register arguments).

jhb: Maybe just say the type of the 3rd arg depends on the operation (and document the type for each…
kibAuthorUnsubmitted
Done
Inline Actions

I pushed everything but this change, the review is updated with the man page changes.

kib: I pushed everything but this change, the review is updated with the man page changes.
Unless otherwise noted below for a specific operation,
emasteUnsubmitted
Done
Inline Actions

maybe "with type dependent on the specific operation"

or maybe

can take an additional third argument
.Fa arg.
Unless otherwise noted below for a specific operation,
.Fa arg
has type
.Vt int .
emaste: maybe "with type dependent on the specific operation" or maybe ``` can take an additional…
.Fa arg
has type
.Vt int .
.Bl -tag -width F_DUP2FD_CLOEXEC .Bl -tag -width F_DUP2FD_CLOEXEC
.It Dv F_DUPFD .It Dv F_DUPFD
Return a new descriptor as follows: Return a new descriptor as follows:
.Pp .Pp
.Bl -bullet -compact -offset 4n .Bl -bullet -compact -offset 4n
.It .It
Lowest numbered available descriptor greater than or equal to Lowest numbered available descriptor greater than or equal to
.Fa arg . .Fa arg .
▲ Show 20 Lines • Show All 121 Lines • ▼ Show 20 Lines
.It Dv F_GET_SEALS .It Dv F_GET_SEALS
Get seals associated with the file, if the underlying filesystem supports seals. Get seals associated with the file, if the underlying filesystem supports seals.
.It Dv F_ISUNIONSTACK .It Dv F_ISUNIONSTACK
Check if the vnode is part of a union stack (either the "union" flag from Check if the vnode is part of a union stack (either the "union" flag from
.Xr mount 2 .Xr mount 2
or unionfs). or unionfs).
This is a hack not intended to be used outside of libc. This is a hack not intended to be used outside of libc.
.It Dv F_KINFO .It Dv F_KINFO
Fills a Fills a
markjUnsubmitted
Done
Inline Actions
.It Dv F_KINFO
- Fills
+ Fills a
.Vt struct kinfo_file
markj:
.Vt struct kinfo_file .Vt struct kinfo_file
for the file referenced by the specified file descriptor. for the file referenced by the specified file descriptor.
The The
.Fa arg .Fa arg
argument should point to the storage for argument should point to the storage for
.Vt struct kinfo_file . .Vt struct kinfo_file .
The The
.Va kf_structsize .Va kf_structsize
▲ Show 20 Lines • Show All 78 Lines • ▼ Show 20 Lines
Seals are on a per-inode basis and require support by the underlying filesystem. Seals are on a per-inode basis and require support by the underlying filesystem.
If the underlying filesystem does not support seals, If the underlying filesystem does not support seals,
.Dv F_ADD_SEALS .Dv F_ADD_SEALS
and and
.Dv F_GET_SEALS .Dv F_GET_SEALS
will fail and return will fail and return
.Dv EINVAL . .Dv EINVAL .
.Pp .Pp
Several commands are available for doing advisory file locking; Several operations are available for doing advisory file locking;
emasteUnsubmitted
Done
Inline Actions

Is "command" or "operation" the better term, in general? I think we should be consistent between this sentence and the added text above/below

emaste: Is "command" or "operation" the better term, in general? I think we should be consistent…
they all operate on the following structure: they all operate on the following structure:
.Bd -literal .Bd -literal
struct flock { struct flock {
off_t l_start; /* starting offset */ off_t l_start; /* starting offset */
off_t l_len; /* len = 0 means until end of file */ off_t l_len; /* len = 0 means until end of file */
pid_t l_pid; /* lock owner */ pid_t l_pid; /* lock owner */
short l_type; /* lock type: read/write, etc. */ short l_type; /* lock type: read/write, etc. */
short l_whence; /* type of l_start */ short l_whence; /* type of l_start */
int l_sysid; /* remote system id or zero for local */ int l_sysid; /* remote system id or zero for local */
}; };
.Ed .Ed
These advisory file locking operations take a pointer to
emasteUnsubmitted
Done
Inline Actions

These commands take a pointer to struct flock as the third argument arg.
or
These advisory file locking commands take a pointer to struct flock as the third argument arg.

emaste: These commands take a pointer to struct flock as the third argument arg. or These advisory file…
emasteUnsubmitted
Done
Inline Actions

Maybe "operations" here too for consistency?
But from the context this one is clear so I don't mind either way.

emaste: Maybe "operations" here too for consistency? But from the context this one is clear so I don't…
.Vt struct flock
as the third argument
.Fa arg .
The commands available for advisory record locking are as follows: The commands available for advisory record locking are as follows:
.Bl -tag -width F_SETLKWX .Bl -tag -width F_SETLKWX
.It Dv F_GETLK .It Dv F_GETLK
Get the first lock that blocks the lock description pointed to by the Get the first lock that blocks the lock description pointed to by the
third argument, third argument,
.Fa arg , .Fa arg ,
taken as a pointer to a taken as a pointer to a
.Fa "struct flock" .Fa "struct flock"
▲ Show 20 Lines • Show All 477 Lines • Show Last 20 Lines
View Options

lib/libveriexec/gbl_check.c

Loading...
View Options

lib/libveriexec/libveriexec.h

Loading...
View Options

lib/libveriexec/veriexec_get.c

Loading...
View Options

sbin/veriexec/Makefile.depend

Loading...
View Options

sbin/veriexec/veriexec.8

Loading...
View Options

sbin/veriexec/veriexec.c

Loading...
View Options

sys/conf/files

Loading...
View Options

sys/conf/options

Loading...
View Options

sys/security/mac_grantbylabel/mac_grantbylabel.h

Loading...
View Options

sys/security/mac_grantbylabel/mac_grantbylabel.c

Loading...