These are non-standard and specific to the version used in loader. We
have some desire to recognize symlinks to avoid filtering out kernel
symlinks in the autodetection bits when they would be perfectly fine to
`load`.
This won't be usable right away, so any impending use will need to be
careful to account for nil.
Reported by: leres
When lua_chown is used to call chown(2) internally, it first resolves
the user and/or group by calling the getpwnam_r(3) and getgrnam_r(3)
functions, respectively. However, although it checks for errors, it does
not check when entries are not found (which is not an error), which
means that the buffer will be set to NULL, and since lua_chown attempts
to access the NULL structure, it will receive a SIGSEGV signal.
Reviewed by: imp@
Approved by: imp@
Differential Revision: https://reviews.freebsd.org/D55172
lposix is the last holdout of modules built into flua until we can fix
the module design to have the right parts require()able. Address a
valid bug in lua_read() found at a higher WARNS and drop the override
entirely. Some of the modules could possibly be re-evaluated.
Fixes: c2caf3b331 ("flua: lposix: add more useful functions [...]")
Reported by: des
Reviewed by: des
Sponsored by: Klara, Inc.
Sponsored by: NetApp, Inc.
flua is a standalone third-party component that deserves its own
package. In particular, this means things can use flua without
having to depend on FreeBSD-utilities, which will be useful as
more base utilities use flua.
This saves ~500kB in FreeBSD-utilities for systems which don't
need flua.
MFC after: 3 days
Reviewed by: kevans
Sponsored by: https://www.patreon.com/bsdivy
Differential Revision: https://reviews.freebsd.org/D53161
Local tree pollution let this escape. *sigh*.
Pointy hat: kevans
Pointy hat: kevans
Pointy hat: kevans
Fixes: 9c7db0931d ("flua: move lposix back into flua for now")
The real luaposix is structured differently, and our builtin version
tends to model that in its own special way. Build it back in until we
get the shlib model just right to unbreak nuageinit, among other things.
This is a partial revert of the below-referenced commit; the other two
modules are simple, though, and were accurately split out.
Reported by: markj
Fixes: b11a5709ec ("flua: kick out the remaining builtin modules")
Bootstrap flua has some magic now to handle modules by building them in
and discovering them via linker sets. This is slightly cleaner than
always building them in and baking them into loadedlibs for both
bootstrap and system flua.
Adjust the stand build now that these three libs have their own new
homes.
Reviewed by: bapt, emaste
Differential Revision: https://reviews.freebsd.org/D51891
This version builds every module into the flua binary itself, since all
of the bootstrap tools are built -DNO_SHARED. As a result, we also
cannot dlsym(), so we can't really discover the names of our newly
builtin modules. Instead, just build out a linker set with all of our
luaopen_*() functions to register everything up-front.
Building in all of the modules isn't strictly necessary, but it means
that we have an example of how to add a bootstrap module everywhere you
go and one doesn't need to consider whether bootstrap flua can use a
module when writing scripts. On my build machine, the consequence on
our binary size is an increase from around 1.6M -> 1.9M, which isn't
really that bad.
.lua modules can install into their usual path below $WORLDTMP/legacy
and we'll pick them up automagically by way of the ctor that sets up
LUA_PATH early on.
This re-lands bootstrap module support with a more sensible subset, and
after having verified that it cross-builds fine on macOS and Linux -- we
cannot do libfreebsd on !FreeBSD because it's more system header
dependant. We also need to bootstrap libmd to bring in libhash, and
libucl + libyaml.
Reviewed by: bapt, emaste (both previous version)
Differential Revision: https://reviews.freebsd.org/D51890
This reverts commit 1953a12ee2, because it
cannot work at all on macOS without more work, at a minimum. We use
linker sets for module discovery, but we don't have a version of this
that works for mach-o at the moment.
Bootstrap flua has some magic now to handle modules by building them in
and discovering them via linker sets. This is slightly cleaner than
always building them in and baking them into loadedlibs for both
bootstrap and system flua.
Adjust the stand build now that these three libs have their own new
homes.
Reviewed by: bapt, emaste
Differential Revision: https://reviews.freebsd.org/D51891
This version builds every module into the flua binary itself, since all
of the bootstrap tools are built -DNO_SHARED. As a result, we also
cannot dlsym(), so we can't really discover the names of our newly
builtin modules. Instead, just build out a linker set with all of our
luaopen_*() functions to register everything up-front.
Building in all of the modules isn't strictly necessary, but it means
that we have an example of how to add a bootstrap module everywhere you
go and one doesn't need to consider whether bootstrap flua can use a
module when writing scripts. On my build machine, the consequence on
our binary size is an increase from around 1.6M -> 1.9M, which isn't
really that bad.
.lua modules can install into their usual path below $WORLDTMP/legacy
and we'll pick them up automagically by way of the ctor that sets up
LUA_PATH early on.
Reviewed by: bapt, emaste
Differential Revision: https://reviews.freebsd.org/D51890
This allows us to do things like:
```
local fp = assert(fbsd.exec({"ls", "-l"}, true))
local fpout = assert(fp:stdout())
while true do
local line = fpout:read("l")
if not line then break end
print("Read: " .. line)
end
fp:close()
```
The makeman lua rewrite will use it to capture `make showconfig` output
for processing.
Reviewed by: bapt
Differential Revision: https://reviews.freebsd.org/D50539
This gives us some way to be able to write to stdin if we want to, or
as a future improvement, will allow us to extract stdout from the
process. The handle is setup to close and waitpid() on close/gc so that
existing users wouldn't necessarily leak for the lifetime of the script
if they weren't adopted to the new model.
Reviewed by: bapt
Differential Revision: https://reviews.freebsd.org/D50538
Additionally, there's no way to get to the end without a valid
stdin_pipe[1] at the moment, so don't check for it. stdin_pipe[0] is
closed earlier, as the parent shouldn't need the read-side of the pipe.
While we're here, also free the file actions earlier and on error --
they're not necessary once posix_spawnp() has returned.
Reviewed by: bapt
Differential Revision: https://reviews.freebsd.org/D50537
The posix module is subdivided according to C headers; for instance,
posix.unistd contains routines available from unistd.h, such as
chown(2).
A quirk of our implementation is that each of the modules is a direct
entry in the global table. That is, there is no "posix" table.
Instead, "posix.foo" and "posix.bar.baz" are both top-level tables.
This is surprising and goes against Lua's shorthand of using "." to
access keys in a table. lua-posix also doesn't work this way.
Rework things so that "posix" and "posix.sys" are proper tables.
Existing flua code which uses require() to bind posix submodules to a
name will be unaffected. Code which accesses them directly using
something like _G["posix.sys.utsname"].uname() will be broken, but I
don't think anything like that exists. In particular, it is now
possible to call posix.sys.utsname.uname() without any require
statements.
Reviewed by: imp, bapt
MFC after: 2 weeks
Differential Revision: https://reviews.freebsd.org/D51158
The implementation of chown() in the posix module handles user and group
names as well as numeric IDs. When resolving names, be sure to use
reentrant lookup functions rather than assuming it's safe to clobber the
internal buffers used by getpwnam() and getgrnam().
Fix some style nits while here.
Reviewed by: imp, bapt
MFC after: 2 weeks
Differential Revision: https://reviews.freebsd.org/D46555
This matches the interface of lposix, although I do wonder why they went
with execp rather than execvp for the function name here.
Sponsored by: The FreeBSD Foundation
Differential Revision: https://reviews.freebsd.org/D50177
The key insight here is that the luaL_check*() and luaL_opt*() functions
will happily take indexes that are larger than the stack top and print a
useful error message.
This means that there is no need to check if too few arguments have been
received prior to checking the types of individual arguments.
This patch also replaces a couple reimplementations of luaL_opt*()
functions with the luaL helpers.
References: https://www.lua.org/manual/5.4/manual.html#4.1.2
Reviewed by: emaste, kevans
Sponsored by: The FreeBSD Foundation
Differential Revision: https://reviews.freebsd.org/D50273
Flua is a minimal Lua interpreter integrated into the FreeBSD base
system. It is intended for internal use and is not designed for
general-purpose scripting or use by third-party applications, and was
originally intentionally undocumented.
There have been questions about its purpose, and questions about the
available functionality from internal users, so provide a minimal man
page including these details.
Reviewed by: kevans, Isaac Freund <[email protected]>
Sponsored by: The FreeBSD Foundation
Differential Revision: https://reviews.freebsd.org/D49835
Each one is an arbitrary string associated with a jail. It can be set
upon jail creation or added/modified later:
> jail -cm ... meta="tag1=value1 tag2=value2" env="configuration"
The values are not inherited from the parent jail.
A parent jail can read both metadata parameters, while a child jail can
read only env via security.jail.env sysctl.
The maximum size of meta or env per jail is controlled by the
global security.jail.meta_maxbufsize sysctl. Decreasing it does not
alter the existing meta information.
Each metadata buffer can be handled as a set of key=value\n strings:
> jail -cm ... meta="$(echo k1=v1; echo k2=v2)" env.1=one
> jls meta.k2 env.1 meta.k1
While meta.k1= resets the value to an empty string, the meta.k1 without
the equal sign removes the given key.
Relnotes: yes
Reviewed by: jamie
Tested by: dch
Sponsored by: SkunkWerks GmbH
Differential Revision: https://reviews.freebsd.org/D47668
The fnmatch function matches a string against a shell-style filename
pattern. It is a complex function and cannot easily be implenented
using regular expressions. Adding fnmatch to flua increases the amd64
binary by less than 1 KB.
Approved by: markj
MFC after: 3 days
Differential Revision: https://reviews.freebsd.org/D46849
- Provide a sys/md4.h in the cross-build environment to fix bootstrap
of libmd.
- flua now exposes WTRAPPED which isn't incredibly common- make it
conditional, we probably won't be using it in any bootstrap context
any time soon.
Fixes: 442e0975ee ("Consolidate md4 implementations written in C")
Fixes: c2caf3b331 ("flua: posix: add more useful functions [...]")
unistd:
- _exit
- close
- fork
- getpid
- pipe
- read
- write
libgen:
- basename, dirname
stdlib:
- realpath
These are sufficient for a number of real world scenarios. In our first
application of them, we use the libgen+stdlib additions to grab the
script dir based on argv[0]. The unistd assortment is then used to
outsource a bunch of work to forks and report back to the main process.
Reviewed by: emaste, imp
Differential Revision: https://reviews.freebsd.org/D39083
Add bindings for kenv(2) right now only get() has been created
it allows do dump into a key/value table the kernel environement if
no argument is passed, or it returns the value associated to the
provided key.
Reviewed by: imp, kevans, markj
Accepted by: imp, kevans
Differential Revision: https://reviews.freebsd.org/D46654
Follow the path of what is done with bsnmp, build the modules along
with the main binary, this allows to build the modules at a moment
where all needed libraries are already built and available in the
linker path instead of having to declare all the libraries which a
flua module will be linked to in _prebuild_libs.
Discused with: markj
Reviewed by: markj, jrtc27, kevans, imp
Accepted by: kevans, imp
Differential Revision: https://reviews.freebsd.org/D46610
This module is bundled into flua, it only provides for now the exec
function. The point of the function is to be able to execute a program
without actually executing a shell.
to use it:
fbsd.exec({"id", "bapt"})
Reviewed by: manu
Differential Revision: https://reviews.freebsd.org/D41840
The main difference with the chown in luaposix, is that it checks
and reports if a user or a group do exist when a string is passed
as arguments
Reviewed by: kevans
Differential Revision: https://reviews.freebsd.org/D37479
This eliminates a lot of stat() calls that happen when lualoader renders the
menu with the default settings, and greatly speeds up rendering on my
laptop.
ftype is nil if loader/loader.efi hasn't been updated yet, falling back to
lfs.attributes() to test.
This is technically incompatible with lfs, but not in a particularly
terrible way.
Reviewed-by: cem
MFC-after: 4 days
Differential Revision: https://reviews.freebsd.org/D27542
flua does have some specific bits that will include luaconf.h, but the
definition of LUA_USE_DLOPEN for those won't matter. This belongs in liblua
instead.
To expand on my previous commit, which was a little sparse with details,
it's not really safe to allow LUA_USE_DLOPEN with host lib paths being used.
The host system could have an entirely different lua version and this could
cause us to crash and burn.
If we want to revive this later, we need to make sure to define c module
paths inside OBJDIR that are compiled against whatever version we've
bootstrapped.
Pointy hat: kevans
libucl comes with a Lua library binding. Build it into flua.
This lets us parse/generate config files in the various formats supported by
libucl with flua. For example, the following script will detect the format of
an object written to stdin as one of UCL config, JSON, or YAML and write it to
stdout as pretty-printed JSON:
local ucl = require('ucl')
local parser = ucl.parser()
parser:parse_string(io.read('*a'))
local obj = parser:get_object()
print(ucl.to_format(obj, 'json'))
Reviewed by: kevans, pstef
Approved by: mmacy (mentor)
Relnotes: yes
Differential Revision: https://reviews.freebsd.org/D25009
The bootstrap flua should not be used for REPL-like activities; exclude it
to save the dependency on libedit and not waste time with it.
X-MFC-With: r359453
Kyle Evans