libc: gen: refactor execvPe() for readability

The current incarnation of execvPe() is a bit messy, and it can be
rather difficult to reason about whether we're actually doing the right
thing with ou

libc: gen: refactor execvPe() for readability

The current incarnation of execvPe() is a bit messy, and it can be
rather difficult to reason about whether we're actually doing the right
thing with our errors. We have two cases in which we may enter the loop:

1.) We have a name that has no slashes in it, and we enter the loop
normally through our strsep() logic to process $PATH

2.) We have a name with at least one slash, in which case we jump into
the middle of the loop then bail after precisely the one iteration
if we failed

Both paths will exit the loop if we failed, either via jumping to the
`done` label to preserve an errno or into the path that clobbers errno.
Clobbering errno for case #2 above would seem to be wrong, as we did not
actually search -- this would seem to be what POSIX expects, as well,
based on expectations of the conformance test suite.

Simplify reasoning about the two paths by splitting out an execvPe_prog
that does the execve(2) call specifically, and returns based on whether
the error would be fatal in a PATH search or not. For the
relative/absolute case, we can just ignore the return value and keep
errno intact. The search case gets simplified to return early if
we hit a fatal error, or continue until the end and clobber errno if
we did not find a suitable candidate.

Another posix_spawnp() test is added to confirm that we didn't break our
EACCES behavior in the process.

Reviewed by: des, markj
Sponsored by: Klara, Inc.
Differential Revision: https://reviews.freebsd.org/D51629

show more ...

libc: treat execvpe as a week symbol

Some program intercepts the execvpe call in runtime. At the same time, the
implementation of posix_spwan use execvpe. If execvpe is intercepted and
then calls po

libc: treat execvpe as a week symbol

Some program intercepts the execvpe call in runtime. At the same time, the
implementation of posix_spwan use execvpe. If execvpe is intercepted and
then calls posix_spawn when intercepted. It wil create a infinite loop
because the intercepted execvpe will spawn a posix_spwan call and will be
intercepted again.

See https://github.com/rizsotto/Bear/issues/557 for reference.

Reviewed by: brooks, kib, emaste
Sponsored by: FreeBSD Foundation
Differential Revision: https://reviews.freebsd.org/D49733

show more ...

libc: expose execvpe for Linux compat

We already implemented execvpe internally with an _ prefix in libc so
go ahead and expose it for compatibility with Linux.

This reverts c605eea952146348e5e1ad5

libc: expose execvpe for Linux compat

We already implemented execvpe internally with an _ prefix in libc so
go ahead and expose it for compatibility with Linux.

This reverts c605eea952146348e5e1ad5cab6c127d7a1bd164.

Bump __FreeBSD_version for the addition and add definitions to supress
compat shims in libzfs (zfs changes were merged from upstream).

PR: 275370 (request and exp-run (thanks antoine!))
Reviewed by: kevans
Differential Revision: https://reviews.freebsd.org/D42846

show more ...

lib: 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

lib: 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 ...

Remove $FreeBSD$: one-line .c pattern

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

libc: move declaration of 'char **environ' to common private header

Suggested by: imp
Reviewed by: markj
Tested by: markj (aarch64)
Sponsored by: The FreeBSD Foundation
MFC after: 3 weeks
Differenti

libc: move declaration of 'char **environ' to common private header

Suggested by: imp
Reviewed by: markj
Tested by: markj (aarch64)
Sponsored by: The FreeBSD Foundation
MFC after: 3 weeks
Differential revision: https://reviews.freebsd.org/D37220

show more ...

execvPe: obviate the need for potentially large stack allocations

Some environments in which execvPe may be called have a limited amount of
stack available. Currently, it avoidably allocates a segme

execvPe: obviate the need for potentially large stack allocations

Some environments in which execvPe may be called have a limited amount of
stack available. Currently, it avoidably allocates a segment on the stack
large enough to hold PATH so that it may be mutated and use strsep() for
easy parsing. This logic is now rewritten to just operate on the immutable
string passed in and do the necessary math to extract individual paths,
since it will be copying out those segments to another buffer anyways and
piecing them together with the name for a full path.

Additional size is also needed for the stack in posix_spawnp(), because it
may need to push all of argv to the stack and rebuild the command with sh in
front of it. We'll make sure it's properly aligned for the new thread, but
future work should likely make rfork_thread a little easier to use by
ensuring proper alignment.

Some trivial cleanup has been done with a couple of error writes, moving
strings into char arrays for use with the less fragile sizeof().

Reported by: Andrew Gierth <andrew_tao173.riddles.org.uk>
Reviewed by: jilles, kib, Andrew Gierth
MFC after: 1 week
Differential Revision: https://reviews.freebsd.org/D25038

show more ...

execvp: fix up the ENOEXEC fallback

If execve fails with ENOEXEC, execvp is expected to rebuild the command
with /bin/sh instead and try again.

The previous version did this, but overlooked two det

execvp: fix up the ENOEXEC fallback

If execve fails with ENOEXEC, execvp is expected to rebuild the command
with /bin/sh instead and try again.

The previous version did this, but overlooked two details:

argv[0] can conceivably be NULL, in which case memp would never get
terminated. We must allocate no less than three * sizeof(char *) so we can
properly terminate at all times. For the non-NULL argv standard case, we
count all the non-NULL elements and actually skip the first argument, so we
end up capturing the NULL terminator in our bcopy().

The second detail is that the spec is actually worded such that we should
have been preserving argv[0] as passed to execvp:

"[...] executed command shall be as if the process invoked the sh utility
using execl() as follows:

execl(<shell path>, arg0, file, arg1, ..., (char *)0);

where <shell path> is an unspecified pathname for the sh utility, file is
the process image file, and for execvp(), where arg0, arg1, and so on
correspond to the values passed to execvp() in argv[0], argv[1], and so on."

So we make this change at this time as well, while we're already touching
it. We decidedly can't preserve a NULL argv[0] as this would be incredibly,
incredibly fragile, so we retain our legacy behavior of using "sh" for
argv[] in this specific instance.

Some light tests are added to try and detect some components of handling the
ENOEXEC fallback; posix_spawnp_enoexec_fallback_null_argv0 is likely not
100% reliable, but it at least won't raise false-alarms and it did result in
useful failures with pre-change libc on my machine.

This is a secondary change in D25038.

Reported by: Andrew Gierth <andrew_tao173.riddles.org.uk>
Reviewed by: jilles, kib, Andrew Gierth
MFC after: 1 week

show more ...

libc: gen: refactor execvPe() for readability

The current incarnation of execvPe() is a bit messy, and it can be
rather difficult to reason about whether we're actually doing the right
thing with ou

libc: gen: refactor execvPe() for readability

The current incarnation of execvPe() is a bit messy, and it can be
rather difficult to reason about whether we're actually doing the right
thing with our errors. We have two cases in which we may enter the loop:

1.) We have a name that has no slashes in it, and we enter the loop
normally through our strsep() logic to process $PATH

2.) We have a name with at least one slash, in which case we jump into
the middle of the loop then bail after precisely the one iteration
if we failed

Both paths will exit the loop if we failed, either via jumping to the
`done` label to preserve an errno or into the path that clobbers errno.
Clobbering errno for case #2 above would seem to be wrong, as we did not
actually search -- this would seem to be what POSIX expects, as well,
based on expectations of the conformance test suite.

Simplify reasoning about the two paths by splitting out an execvPe_prog
that does the execve(2) call specifically, and returns based on whether
the error would be fatal in a PATH search or not. For the
relative/absolute case, we can just ignore the return value and keep
errno intact. The search case gets simplified to return early if
we hit a fatal error, or continue until the end and clobber errno if
we did not find a suitable candidate.

Another posix_spawnp() test is added to confirm that we didn't break our
EACCES behavior in the process.

Reviewed by: des, markj
Sponsored by: Klara, Inc.
Differential Revision: https://reviews.freebsd.org/D51629

show more ...

libc: treat execvpe as a week symbol

Some program intercepts the execvpe call in runtime. At the same time, the
implementation of posix_spwan use execvpe. If execvpe is intercepted and
then calls po

libc: treat execvpe as a week symbol

Some program intercepts the execvpe call in runtime. At the same time, the
implementation of posix_spwan use execvpe. If execvpe is intercepted and
then calls posix_spawn when intercepted. It wil create a infinite loop
because the intercepted execvpe will spawn a posix_spwan call and will be
intercepted again.

See https://github.com/rizsotto/Bear/issues/557 for reference.

Reviewed by: brooks, kib, emaste
Sponsored by: FreeBSD Foundation
Differential Revision: https://reviews.freebsd.org/D49733

show more ...

libc: expose execvpe for Linux compat

We already implemented execvpe internally with an _ prefix in libc so
go ahead and expose it for compatibility with Linux.

This reverts c605eea952146348e5e1ad5

libc: expose execvpe for Linux compat

We already implemented execvpe internally with an _ prefix in libc so
go ahead and expose it for compatibility with Linux.

This reverts c605eea952146348e5e1ad5cab6c127d7a1bd164.

Bump __FreeBSD_version for the addition and add definitions to supress
compat shims in libzfs (zfs changes were merged from upstream).

PR: 275370 (request and exp-run (thanks antoine!))
Reviewed by: kevans
Differential Revision: https://reviews.freebsd.org/D42846

show more ...

lib: 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

lib: 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 ...

Remove $FreeBSD$: one-line .c pattern

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

libc: move declaration of 'char **environ' to common private header

Suggested by: imp
Reviewed by: markj
Tested by: markj (aarch64)
Sponsored by: The FreeBSD Foundation
MFC after: 3 weeks
Differenti

libc: move declaration of 'char **environ' to common private header

Suggested by: imp
Reviewed by: markj
Tested by: markj (aarch64)
Sponsored by: The FreeBSD Foundation
MFC after: 3 weeks
Differential revision: https://reviews.freebsd.org/D37220

show more ...

execvPe: obviate the need for potentially large stack allocations

Some environments in which execvPe may be called have a limited amount of
stack available. Currently, it avoidably allocates a segme

execvPe: obviate the need for potentially large stack allocations

Some environments in which execvPe may be called have a limited amount of
stack available. Currently, it avoidably allocates a segment on the stack
large enough to hold PATH so that it may be mutated and use strsep() for
easy parsing. This logic is now rewritten to just operate on the immutable
string passed in and do the necessary math to extract individual paths,
since it will be copying out those segments to another buffer anyways and
piecing them together with the name for a full path.

Additional size is also needed for the stack in posix_spawnp(), because it
may need to push all of argv to the stack and rebuild the command with sh in
front of it. We'll make sure it's properly aligned for the new thread, but
future work should likely make rfork_thread a little easier to use by
ensuring proper alignment.

Some trivial cleanup has been done with a couple of error writes, moving
strings into char arrays for use with the less fragile sizeof().

Reported by: Andrew Gierth <andrew_tao173.riddles.org.uk>
Reviewed by: jilles, kib, Andrew Gierth
MFC after: 1 week
Differential Revision: https://reviews.freebsd.org/D25038

show more ...

execvp: fix up the ENOEXEC fallback

If execve fails with ENOEXEC, execvp is expected to rebuild the command
with /bin/sh instead and try again.

The previous version did this, but overlooked two det

execvp: fix up the ENOEXEC fallback

If execve fails with ENOEXEC, execvp is expected to rebuild the command
with /bin/sh instead and try again.

The previous version did this, but overlooked two details:

argv[0] can conceivably be NULL, in which case memp would never get
terminated. We must allocate no less than three * sizeof(char *) so we can
properly terminate at all times. For the non-NULL argv standard case, we
count all the non-NULL elements and actually skip the first argument, so we
end up capturing the NULL terminator in our bcopy().

The second detail is that the spec is actually worded such that we should
have been preserving argv[0] as passed to execvp:

"[...] executed command shall be as if the process invoked the sh utility
using execl() as follows:

execl(<shell path>, arg0, file, arg1, ..., (char *)0);

where <shell path> is an unspecified pathname for the sh utility, file is
the process image file, and for execvp(), where arg0, arg1, and so on
correspond to the values passed to execvp() in argv[0], argv[1], and so on."

So we make this change at this time as well, while we're already touching
it. We decidedly can't preserve a NULL argv[0] as this would be incredibly,
incredibly fragile, so we retain our legacy behavior of using "sh" for
argv[] in this specific instance.

Some light tests are added to try and detect some components of handling the
ENOEXEC fallback; posix_spawnp_enoexec_fallback_null_argv0 is likely not
100% reliable, but it at least won't raise false-alarms and it did result in
useful failures with pre-change libc on my machine.

This is a secondary change in D25038.

Reported by: Andrew Gierth <andrew_tao173.riddles.org.uk>
Reviewed by: jilles, kib, Andrew Gierth
MFC after: 1 week

show more ...

Clean up the vcs ID strings in libc's gen/ directory.

- Move CSRG IDs into __SCCSID().
- When a file has been copied, consistently use 'From: <tag>' for strings
referencing the version of the sour

Clean up the vcs ID strings in libc's gen/ directory.

- Move CSRG IDs into __SCCSID().
- When a file has been copied, consistently use 'From: <tag>' for strings
referencing the version of the source file copied from in the license
block comment.
- Some of the 'From:' tags were using $FreeBSD$ that was being expanded on
each checkout. Fix those to hardcode the FreeBSD tag from the file that
was copied at the time of the copy.
- When multiple strings are present list them in "chronological" order,
so CSRG (__SCCSID) before FreeBSD (__FBSDID). If a file came from
OtherBSD and contains a CSRG ID from the OtherBSD file, use the order
CSRG -> OtherBSD -> FreeBSD.

Reviewed by: imp
Differential Revision: https://reviews.freebsd.org/D15831

show more ...

Merge ^/head r325999 through r326131.

General further adoption of SPDX licensing ID tags.

Mainly focus on files that use BSD 3-Clause license.

The Software Package Data Exchange (SPDX) group provides a specification
to make it easier f

General further adoption of SPDX licensing ID tags.

Mainly focus on files that use BSD 3-Clause license.

The Software Package Data Exchange (SPDX) group provides a specification
to make it easier for automated tools to detect and summarize well known
opensource licenses. We are gradually adopting the specification, noting
that the tags are considered only advisory and do not, in any way,
superceed or replace the license texts.

Special thanks to Wind River for providing access to "The Duke of
Highlander" tool: an older (2014) run over FreeBSD tree was useful as a
starting point.

show more ...

Merge ^/head r314420 through r314481.

Renumber copyright clause 4

Renumber cluase 4 to 3, per what everybody else did when BSD granted
them permission to remove clause 3. My insistance on keeping the same
numbering for legal reasons is

Renumber copyright clause 4

Renumber cluase 4 to 3, per what everybody else did when BSD granted
them permission to remove clause 3. My insistance on keeping the same
numbering for legal reasons is too pedantic, so give up on that point.

Submitted by: Jan Schaumann <jschauma@stevens.edu>
Pull Request: https://github.com/freebsd/freebsd/pull/96

show more ...

libc: do not include <sys/types.h> where <sys/param.h> was already included

According to style(9):
> normally, include <sys/types.h> OR <sys/param.h>, but not both.
(<sys/param.h> already includes <

libc: do not include <sys/types.h> where <sys/param.h> was already included

According to style(9):
> normally, include <sys/types.h> OR <sys/param.h>, but not both.
(<sys/param.h> already includes <sys/types.h> when LOCORE is not defined).

show more ...

Merge from head

Sponsored by: Gandi.net

Merge from head

Merge from head