1. 50+% of NO_PIE use is fixed by adding -fPIC to INTERNALLIB and other
build-only utility libraries.
2. Another 40% is fixed by generating _pic.a variants of various libraries.
3. Some of the NO_PIE use is a bit absurd as it is disabling PIE (and ASLR)
where it never would work anyhow, such as csu or loader. This suggests
there may be better ways of adding support to the tree. Many of these
cases can be fixed such that -fPIE will work but there is really no
reason to have it in those cases.
4. Some of the uses are working around hacks done to some Makefiles that are
really building libraries but have been using bsd.prog.mk because the code
is cleaner. Had they been using bsd.lib.mk then NO_PIE would not have
been needed.
We likely do want to enable PIE by default (opt-out) for non-tree consumers
(such as ports). For in-tree though we probably want to only enable PIE
(opt-in) for common attack targets such as remote service daemons and setuid
utilities. This is also a great performance compromise since ASLR is expected
to reduce performance. As such it does not make sense to enable it in all
utilities such as ls(1) that have little benefit to having it enabled.
Reported by: kib
This is currently an opt-in build flag. Once ASLR support is ready and stable
it should changed to opt-out and be enabled by default along with ASLR.
Each application Makefile uses opt-out to ensure that ASLR will be enabled by
default in new directories when the system is compiled with PIE/ASLR. [2]
Mark known build failures as NO_PIE for now.
The only known runtime failure was rtld.
[1] http://www.bsdcan.org/2014/schedule/events/452.en.html
Submitted by: Shawn Webb <lattera@gmail.com>
Discussed between: des@ and Shawn Webb [2]
current version of FreeBSD, this isn't guarenteed by the API. Custom
security modules, or future implementations of the setuid and setgid
may fail.
PR: bin/172289
PR: bin/172290
PR: bin/172291
Submittud by: Erik Cederstrand <erik@cederstrand.dk>
Discussed by: freebsd-security
Approved by: cperciva
MFC after: 1 week
print-jobs which have last-modification times that are in the future.
This shouldn't happen, of course, but it can. And when it did happen,
the previous check could cause completely-spooled jobs to sit in the
queue for 20 minutes per job. The new code waits until the last-modify
time is not changing, instead of making decisions based on the specific
value of last-modify.
MFC after: 2 weeks
so that the checking will wind up with the correct mode-bits in
the case where the initial open() of that lock file will create it.
Due to this bug, the first job ever sent to a queue could leave
that queue in a "printing is disabled" state.
PR: 93469
Submitted by: Michael Szklarski of kco.com.pl
MFC after: 1 week
the file will be created with the right access, if the call to open()
does create it. Also fix the other call to umask() to turn off
"write others", just as a matter of general safety.
PR: 74418
MFC after: 4 days
sure the data file has been completely transfered before starting to
print it. This is needed because some implementations of lpr will send
the control-file for a print job before sending the matching data-files,
and that can cause problems if the receiving host is a busy print-server.
MFC after: 2 weeks
when reading/writing spool files. I intend to do a more elaborate
version, but I want to get this much in before 4.9-release. As written,
this results in no change to the object code.
Submitted by: John-Mark Gurney
Reviewed by: /sbin/md5
MFC after: 4 days
format of 'sccsid' lines so they consistently match style(9)
guidelines. Inspired by recent update to lpd.c by charnier.
Reviewed by: discussed on cvs-src & with bde and obrien
MFC after: 15 days
mainly so the compiler can correctly do printf-style parameter checking.
Some minor improvements to a few of the error messages, but the main
goal here is to get rid of a few more compile-time warning messages.
MFC after: 5 days
of them to keep better track of which-is-which (multiple variables were
named 'pid'). Moved a global pid-variable into the only routine that
used it. Net result: fixes two compile-time warnings...
MFC after: 2 weeks
This is a boolean option, and if it is specified in a print queue
for a remote host, it causes lpd to resend the data file for each
copy the user requested on 'lpr -#n'. This is useful for network
printers which accept lpd-style jobs, but which ignore the control
file (and thus they ignore any request for multiple copies).
PR: 25635
Reviewed by: short review on freebsd-audit
MFC after: 6 days
for what is currently the '-p' parameter. '-s' is what NetBSD
used (and they implemented it before I added -p in FreeBSD), and
it also matches the '-s' option in syslogd. Someone in OpenBSD
land had also talked about adding a '-s' option, but it hasn't
happened yet.
MFC after: 5 days
"confused" about it being unassigned. In fact, gcc was right. Fix the
real problem by setting that variable before break-ing out of a select
statement so gcc is happy, and then remove the unnecessary assignment.
Reported by: a user wondering why lpd syslog-ed about "compiler confusion"
MFC after: 12 days
input file and any temporary (filter) file are closed upon return, and
that is generally done at the end of the routine. This should make it
easier for a later update (not yet written) to implement a "resend_copies"
option.
MFC after: 12 days
remote machines. Now they really are handled *exactly* the same as
input filters (if=) for remote queues, except that they are started
with a different set of parameters. This should fix a few subtle
bugs in output-filter processing on such queues. It is a pretty
significant re-arranging of sendfile(), moving some of it to a new
execfilter() routine.
PR: 36552
Reviewed by: no screams from freebsd-audit
MFC after: 12 days
