| Age | Commit message (Collapse) | Author |
|---|
|
problem noted by Juan Francisco Cantero Hurtado (iam (at) juanfra.info)
ok deraadt@
|
|
The problem relates to Perl 5 ("perl") loading modules from the
includes directory array ("@INC") in which the last element is the
current directory ("."). That means that, when "perl" wants to
load a module (during first compilation or during lazy loading of
a module in run-time), perl will look for the module in the current
directory at the end, since '.' is the last include directory in
its array of include directories to seek. The issue is with requiring
libraries that are in "." but are not otherwise installed.
The major problem with this behavior is that it unexpectedly puts
a user at risk whenever they execute any Perl scripts from a directory
that is writable by other accounts on the system. For instance, if
a user is logged in as root and changes directory into /tmp or an
account's home directory, it is possible to now run any shell
commands that are written in C, Python or Ruby without fear.
The same isn't true for any shell commands that are written in Perl,
since a significant proportion of Perl scripts will execute code
in the current working directory whenever they are run. For example,
if a user on a shared system creates the file /tmp/Pod/Perldoc/Toterm.pm,
and then I log in as root, change directory to /tmp, and run "perldoc
perlrun", it will execute the code they have placed in the file.
ok deraadt@
|
|
|
|
|
|
|
|
|
|
This fixes a bug where XSLoader could try to load from a subdir
of the cwd when called via eval. OK afresh1@
|
|
|
|
contains -g by default anyway
problem noted by Edgar Pettijohn (edgar (at) pettijohn-web.com)
ok millert@ kettenis@ deraadt@
|
|
OK bluhm@
|
|
|
|
OK espie@ sthen@ deraadt@
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
Which provides hires `utime`
requested by espie@ OK millert@
|
|
|
|
|
|
ok mikeb@
|
|
No longer necessary with TIB work
from guenther@ ok sthen@
|
|
from guenther@ ok sthen@
|
|
symbol such that hidden symbols get handled properly. Gets rid of the
spurious DT_TEXTREL entries seen with (typically) C++ code.
ok deraadt@, guenther@
|
|
but we first have to make sure that our tree is clean.
ok deraadt@
|
|
to permit it and -ztext to reenable the default of forbidding it.
ok kettenis@
|
|
ok kettenis@
|
|
|
|
actually uses the fact that the PLT is in a writable segment to avoid
the dependency on the __plt_start and __plt_end symbols.
ok deraadt@
|
|
Adapted from a change to mainline gcc while it was still GPLv2.
Original diff found by stefan@
Adaptation by me
ICE caught by ml(at)extensibl(dot)com while he was porting MLton
to OpenBSD.
Ok stefan@
"Go for it" deraadt@
|
|
to always be exported so ld.so can use them. This isn't the Right Thing,
but pushing strict W^X is usefully turning up issues, so unbreak stuff
until we can slog into binutils and do the Right Thing
ok kettenis@
|
|
This greatly speeds up up linking of object files that contain
lots of dwarf2 symbols by caching symbol tables.
Original patch before binutils was switched to GPLv3 from:
https://sourceware.org/ml/binutils/2006-08/msg00334.html
Aaron Miller made us aware of that diff and adapted it to our
in-tree binutils. Many thanks!
Ports build testing on amd64 by krw@
ok deraadt@ krw@
|
|
on a binary by a software builder (ie. packager) to indicate to the kernel
that this software performs W^X violations.
ok kettenis guenther millert
|
|
load binaries without violating W^X. ld.so will make the PLT temporarily
writable (making it non-executable at the same time) to set up the initial
PLT slots and to do non-lazy relocations and restore permissions afterwards.
Make sure you install an updated ld.so before doing a full build.
ok deraadt@
|
|
From Francesco Toscan < f.toscan AT hotmail DOT it >
ok guenther@
|
|
|
|
|
|
|
|
|
|
|
|
C11 feature that is starting to get used in places such as Mesa.
This implementation takes a different approach to upstream and is therefore
not covered by GPLv3.
ok stefan@, jsg@
|
|
|
