/etc/rc.d/pf: Fix for multi-line pf_fallback_rules

Setting multiple pf_fallback_rules in /etc/rc.conf as per the
documentation produces invalid pf syntax due to the lack of echo
quoting $pf_fallback

/etc/rc.d/pf: Fix for multi-line pf_fallback_rules

Setting multiple pf_fallback_rules in /etc/rc.conf as per the
documentation produces invalid pf syntax due to the lack of echo
quoting $pf_fallback_rules in /etc/rc.d/pf. Adding quotes around
the $pf_fallback_rules echo maintains newlines needed for valid
pfctl syntax. Provided patch resolves the issue

Also updating rc.conf(5) to reflect that multi-line pf_fallback_rules
should not include a trailing backslash (\) as line breaks are
needed when passing rules to pfctl via stdin.

PR: 288197
Reviewed by: kp
MFC after: 2 weeks

show more ...

rc.d: add a service jails config to all base system services

This gives more permissions to services (e.g. network access to
services which require this) when they are started as an automatic
servic

rc.d: add a service jails config to all base system services

This gives more permissions to services (e.g. network access to
services which require this) when they are started as an automatic
service jail.

The sshd patch is important for the sshd-related functionality as
described in the man-page in the service jails part.

The location of the added env vars is supposed to allow overriding them
in rc.conf, and to hard-disable the use of svcj for some parts where it
doesn't make sense or will not work.

Only a subset of all of the services are fully tested (I'm running this
since more than a year with various services started as service jails).
The untested parts should be most of the time ok, in some edge-cases
more permissions are needed inside the service jail.
Differential Revision: https://reviews.freebsd.org/D40371

show more ...

Remove $FreeBSD$: one-line sh pattern

Remove /^\s*#[#!]?\s*\$FreeBSD\$.*$\n/

Introduce startmsg and use it in rc scripts

startmsg is a new rc.subr(8) function function to be used instead of
echo(1) when for boot messages. It replaces the often forgotten

check_startmsgs

Introduce startmsg and use it in rc scripts

startmsg is a new rc.subr(8) function function to be used instead of
echo(1) when for boot messages. It replaces the often forgotten

check_startmsgs && echo ...

with

startmsg ...

No functional change intended.

I adjusted the commit message and did some final clean-ups of the patch
before committing.

PR: 255207
Reported by: Jose Luis Duran <jlduran@gmail.com>
Reviewed by: imp, 0mp
Approved by: imp (src)
Differential Revision: https://reviews.freebsd.org/D34514

show more ...

pf: fallback if $pf_rules fails to load

Support loading a default pf ruleset in case of invalid pf.conf.

If no pf rules are loaded pf will pass/allow all traffic, assuming the
kernel is compiled wi

pf: fallback if $pf_rules fails to load

Support loading a default pf ruleset in case of invalid pf.conf.

If no pf rules are loaded pf will pass/allow all traffic, assuming the
kernel is compiled without PF_DEFAULT_TO_DROP, as is the case in
GENERIC.

In other words: if there's a typo in the main pf_rules we would allow
all traffic. The new default rules minimise the impact of this.

If $pf_program (i.e. pfctl) fails to set $pf_fules and
$pf_fallback_rules_enable is YES we will load $pf_fallback_rules_file if
set, or $pf_fallback_rules.

$pf_fallback_rules can include multiple rules, for example to permit
traffic on a management interface.

$pf_fallback_rules_enable defaults to "NO", preserving historic behaviour.

man page changes by ceri@.

PR: 256410
Reviewed by: donner, kp
Sponsored by: semaphor.dk
Differential Revision: https://reviews.freebsd.org/D30791

show more ...

[pf] /etc/rc.d/pf should REQUIRE routing

When a system with pf_enable="YES" in /etc/rc.conf uses hostnames in
/etc/pf.conf, these hostnames cannot be resolved via external nameservers
because the de

[pf] /etc/rc.d/pf should REQUIRE routing

When a system with pf_enable="YES" in /etc/rc.conf uses hostnames in
/etc/pf.conf, these hostnames cannot be resolved via external nameservers
because the default route is not yet set. This results in an empty
(all open) ruleset.

Since r195026 already put netif back to REQUIRE, this change does not affect
the issue that the firewall should rather have been setup before any
network traffic can occur.

PR: 211928
Submitted by: Robert Schulze
Reported by: Robert Schulze
Tested by: Mateusz Kwiatkowski
No objections from: kp
MFC after: 3 days

show more ...

Move the rc framework out of sbin/init into libexec/rc.

The reasons for this are forward looking to pkgbase:
* /sbin/init is a special binary; try not to replace it with
every package update bec

Move the rc framework out of sbin/init into libexec/rc.

The reasons for this are forward looking to pkgbase:
* /sbin/init is a special binary; try not to replace it with
every package update because an rc script was touched.
(a follow-up commit will make init its own package)
* having rc in its own place will allow more easy replacement
of the rc framework with alternatives, such as openrc.

Discussed with: brd (during BSDCam), kmoore
Requested by: cem, bz
PR: 231522
Approved by: re (gjb)

show more ...

Move rc startup scripts from etc/ to sbin/init/

This keeps most startup scripts as CONFS per discussion on src-committers from
back during BSDCan.

Approved by: will (mentor)
Differential Revision:

Move rc startup scripts from etc/ to sbin/init/

This keeps most startup scripts as CONFS per discussion on src-committers from
back during BSDCan.

Approved by: will (mentor)
Differential Revision: https://reviews.freebsd.org/D16466

show more ...

pf: Return non-zero from 'status' if pf is not enabled

In the pf rc.d script the output of `/etc/rc.d/pf status` or `/etc/rc.d/pf
onestatus` always provided an exit status of zero. This made it fidd

pf: Return non-zero from 'status' if pf is not enabled

In the pf rc.d script the output of `/etc/rc.d/pf status` or `/etc/rc.d/pf
onestatus` always provided an exit status of zero. This made it fiddly to
programmatically determine if pf was running or not.

Return a non-zero status if the pf module is not loaded, extend pfctl to have
an option to return an error status if pf is not enabled.

PR: 228632
Submitted by: James Park-Watt <jimmypw AT gmail.com>
MFC after: 1 week

show more ...

pf: reload and resync do the same thing

The reload and resync commands for the startup script do exactly the same
thing, so implement one as a call to the other.

MFC after: 3 weeks

pf: Apply $pf_flags when verifying the pf.conf file

When checking the validity of the pf.conf file also include the user supplied
pf_flags. These flags might overrule macros or specify anchors, whic

pf: Apply $pf_flags when verifying the pf.conf file

When checking the validity of the pf.conf file also include the user supplied
pf_flags. These flags might overrule macros or specify anchors, which we will
apply when actually applying the pf.conf file, so we must also take them into
account when verifying the validity.

Submitted by: Andreas Longwitz <longwitz at incore.de>
MFC after: 3 weeks

show more ...

pf: Do not flush on reload

pfctl only takes the last '-F' argument into account, so this never did what
was intended.

Moreover, there is no reason to flush rules before reloading, because pf keeps

pf: Do not flush on reload

pfctl only takes the last '-F' argument into account, so this never did what
was intended.

Moreover, there is no reason to flush rules before reloading, because pf keeps
track of the rule which created a given state. That means that existing
connections will keep being processed according to the rule which originally
created them. Simply reloading the (new) rules suffices. The new rules will
apply to new connections.

PR: 127814
Submitted by: Andreas Longwitz <longwitz at incore.de>
MFC after: 3 weeks

show more ...

Allow more services to run in vnet jails

After some tests, here are the services that run into a vnet jail:
- defaultroute
- dhclient
- ip6addrctl
- natd
- pf
- pfsync
- pflog (deamon

Allow more services to run in vnet jails

After some tests, here are the services that run into a vnet jail:
- defaultroute
- dhclient
- ip6addrctl
- natd
- pf
- pfsync
- pflog (deamon runs, pflog0 interface usable, but /var/log/pflog not filled)
- rarpd
- route6d (do nothing anyway because obsolete)
- routed (do nothing anyway because obsolete)
- rtsold
- static_arp
- static_ndp

PR: 220530
Submitted by: olivier@freebsd.org

show more ...

- Add descriptions to most of the rc scripts. Those are mostly taken from their
daemon's manpage and probably improved.
- Consistently use "filesystem" not "file system".

Approved by: bapt, brueff

- Add descriptions to most of the rc scripts. Those are mostly taken from their
daemon's manpage and probably improved.
- Consistently use "filesystem" not "file system".

Approved by: bapt, brueffer
Differential Revision: D452

show more ...

pf: Friendly error message for status if pf.ko is not loaded

Check if pf.ko is loaded (i.e. /dev/pf exists) before trying to use it. This
means that '/etc/rc.d/pf status' will no longer return 'pfct

pf: Friendly error message for status if pf.ko is not loaded

Check if pf.ko is loaded (i.e. /dev/pf exists) before trying to use it. This
means that '/etc/rc.d/pf status' will no longer return 'pfctl: /dev/pf: No such
file or directory' but 'pf.ko is not loaded'.

PR: 205671
Submitted by: Johannes Jost Meixner <xmj@FreeBSD.org>

show more ...

Prepare for the removal of set_rcvar() by changing the rcvar=
assignments to the literal values it would have returned.

The concept of set_rcvar() was nice in theory, but the forks
it creates are a

Prepare for the removal of set_rcvar() by changing the rcvar=
assignments to the literal values it would have returned.

The concept of set_rcvar() was nice in theory, but the forks
it creates are a drag on the startup process, which is especially
noticeable on slower systems, such as embedded ones.

During the discussion on freebsd-rc@ a preference was expressed for
using ${name}_enable instead of the literal values. However the
code portability concept doesn't really apply since there are so
many other places where the literal name has to be searched for
and replaced. Also, using the literal value is also a tiny bit
faster than dereferencing the variables, and every little bit helps.

show more ...

Remove redundant keywords.

Submitted by: wxs

Add pf in quiet mode

In regards to the "Starting foo:" type messages at boot time, create and
employ a more generic solution, and use it in the individual rc.d scripts
that also have an $rc_quiet test:

1. Add check_star

In regards to the "Starting foo:" type messages at boot time, create and
employ a more generic solution, and use it in the individual rc.d scripts
that also have an $rc_quiet test:

1. Add check_startmsgs() to rc.subr.
2. In the rc.d scripts that use rc_quiet (and rc.subr) substitute
variations of [ -z "$rc_quiet" ] with check_startmsgs
3. In savecore add a trailing '.' to the end of the message to make it
more consistent with other scripts.
4. In newsyslog remove a : before the terminal '.' since we do not expect
there to be anything printed out in between to make it more consistent.
5. In the following scripts change "quotes" to 'quotes' where no variables
exist in the message: savecore pf newsyslog
6. In the following scripts substitute if/then/fi for the simpler (and
more consistent) check_startmsgs &&: faith stf
7. In the following scripts separate the "Starting foo:" from the terminal
'.' to make them more consistent: moused hostname pf
8. In nfsclient move the message to its own line to avoid a style bug
9. In pf rc_quiet does not apply to the _stop method, so remove the
test there.
10. In motd add 'quotes' around the terminal '.' for consistency

show more ...

Reverse the effect of r193198 for pf and ipfw which will once again
allow them to start after netif. There were too many problems reported
with this change in the short period of time that it lived i

Reverse the effect of r193198 for pf and ipfw which will once again
allow them to start after netif. There were too many problems reported
with this change in the short period of time that it lived in HEAD, and
we are too late in the release cycle to properly shake it out.

IMO the issue of having the firewalls up before the network is still a
valid concern, particularly for pf whose default state is wide open.
However properly solving this issue is going to take some investment
on the part of the people who actually use those tools.

This is not a strict reversion of all the changes for r193198 since it
also included some simplification of the BEFORE/REQUIRE logic which is
still valid for ipfilter and ip6fw.

show more ...

Make the pf and ipfw firewalls start before netif, just like ipfilter
already does. This eliminates a logical inconsistency, and a small
window where the system is open after the network comes up.

As previously discussed, add the svn:executable property to all scripts

The pfctl(8) program is already pretty verbose, so don't print extra
information in quiet mode.

FILESYSTEMS requires root, so requiring both of them is redundant.

Add a dummy script, FILESYSTEMS, which depends on root and mountcritlocal
and takes over mountcritlocal's role as the early / late divider. This
makes it far easier to add rc scripts which need to r

Add a dummy script, FILESYSTEMS, which depends on root and mountcritlocal
and takes over mountcritlocal's role as the early / late divider. This
makes it far easier to add rc scripts which need to run early, such as a
startup script for zfs, which is right around the corner.

This change should be a no-op; I have verified that the only change in
rcorder's output is the insertion of FILESYSTEMS immediately after
mountcritlocal.

MFC after: 3 weeks

show more ...