d/freebsd-dev
1
0
Fork 0
Code Issues Pull Requests Packages Projects Releases Wiki Activity
8ed0ecf802
freebsd-dev/sbin/devfs/devfs.rules

Ignoring revisions in .git-blame-ignore-revs. Click here to bypass and see the normal blame view.

94 lines
2.5 KiB
Plaintext
Raw Normal View History

Add a general mechanism for creating and applying devfs(8) rules in rc(8). It is most useful for applying rules to devfs(5) mount points in /dev or inside jails. The following line of script is sufficient to mount a relatively useful+secure devfs(5) in a jail: devfs_mount_jail /some/jail/dev Some new shell routines available to scripts that source rc.subr(5): o devfs_link - Makes it a little easier to create symlinks o devfs_init_rulesets - Create devfs(8) rulesets from devfs.rules o devfs_set_ruleset - Set a ruleset to a devfs(5) mount o devfs_apply_ruleset - Apply a ruleset to a devfs(5) mount o devfs_domount - Mount devfs(5) and apply some ruleset o devfs_mount_jail - Mount devfs(5) and apply a ruleset appropriate to jails. Additional rulesets can be specified in /etc/devfs.rules. If the devfs_system_ruleset variable is defined in rc.conf and it contains the name of a ruleset defined in /etc/defaults/devfs.rules or user supplied rulesets in /etc/devfs.rules then that ruleset will be applied to /dev at startup by the /etc/rc.d/devfs script. It can also be applied post-startup: /etc/rc.d/devfs start This is a more flexible mechanism than the previous method of using /etc/devfs.conf. However, that method is still available. Note: since devfs(8) doesn't provide any way for creating symlinks as part of a ruleset, anyone wishing to create symlinks in a devfs(5) as part of the bootup sequence will still have to rely on /etc/devfs.conf.
2003-08-20 06:15:18 +00:00
#
# The following are some default rules for devfs(5) mounts.
Correct two typos in comments.
2006-04-22 13:42:49 +00:00
# The format is very simple. Empty lines and lines beginning
Add a general mechanism for creating and applying devfs(8) rules in rc(8). It is most useful for applying rules to devfs(5) mount points in /dev or inside jails. The following line of script is sufficient to mount a relatively useful+secure devfs(5) in a jail: devfs_mount_jail /some/jail/dev Some new shell routines available to scripts that source rc.subr(5): o devfs_link - Makes it a little easier to create symlinks o devfs_init_rulesets - Create devfs(8) rulesets from devfs.rules o devfs_set_ruleset - Set a ruleset to a devfs(5) mount o devfs_apply_ruleset - Apply a ruleset to a devfs(5) mount o devfs_domount - Mount devfs(5) and apply some ruleset o devfs_mount_jail - Mount devfs(5) and apply a ruleset appropriate to jails. Additional rulesets can be specified in /etc/devfs.rules. If the devfs_system_ruleset variable is defined in rc.conf and it contains the name of a ruleset defined in /etc/defaults/devfs.rules or user supplied rulesets in /etc/devfs.rules then that ruleset will be applied to /dev at startup by the /etc/rc.d/devfs script. It can also be applied post-startup: /etc/rc.d/devfs start This is a more flexible mechanism than the previous method of using /etc/devfs.conf. However, that method is still available. Note: since devfs(8) doesn't provide any way for creating symlinks as part of a ruleset, anyone wishing to create symlinks in a devfs(5) as part of the bootup sequence will still have to rely on /etc/devfs.conf.
2003-08-20 06:15:18 +00:00
# with a hash '#' are ignored. If the hash mark occurs anywhere
# other than the beginning of a line, it and any subsequent
# characters will be ignored. A line in between brackets '[]'
# denotes the beginning of a ruleset. In the brackets should
# be a name for the rule and its ruleset number. Any other lines
# will be considered to be the 'action' part of a rule
# passed to the devfs(8) command. These will be passed
# "as-is" to the devfs(8) command with the exception that
# any references to other rulesets will be expanded first. These
Correct two typos in comments.
2006-04-22 13:42:49 +00:00
# references must include a dollar sign '$' in front of the
Add a general mechanism for creating and applying devfs(8) rules in rc(8). It is most useful for applying rules to devfs(5) mount points in /dev or inside jails. The following line of script is sufficient to mount a relatively useful+secure devfs(5) in a jail: devfs_mount_jail /some/jail/dev Some new shell routines available to scripts that source rc.subr(5): o devfs_link - Makes it a little easier to create symlinks o devfs_init_rulesets - Create devfs(8) rulesets from devfs.rules o devfs_set_ruleset - Set a ruleset to a devfs(5) mount o devfs_apply_ruleset - Apply a ruleset to a devfs(5) mount o devfs_domount - Mount devfs(5) and apply some ruleset o devfs_mount_jail - Mount devfs(5) and apply a ruleset appropriate to jails. Additional rulesets can be specified in /etc/devfs.rules. If the devfs_system_ruleset variable is defined in rc.conf and it contains the name of a ruleset defined in /etc/defaults/devfs.rules or user supplied rulesets in /etc/devfs.rules then that ruleset will be applied to /dev at startup by the /etc/rc.d/devfs script. It can also be applied post-startup: /etc/rc.d/devfs start This is a more flexible mechanism than the previous method of using /etc/devfs.conf. However, that method is still available. Note: since devfs(8) doesn't provide any way for creating symlinks as part of a ruleset, anyone wishing to create symlinks in a devfs(5) as part of the bootup sequence will still have to rely on /etc/devfs.conf.
2003-08-20 06:15:18 +00:00
# name to be expanded properly.
#
#
# Very basic and secure ruleset: Hide everything.
# Used as a basis for other rules.
#
[devfsrules_hide_all=1]
add hide
# Basic devices typically necessary.
# Requires: devfsrules_hide_all
#
[devfsrules_unhide_basic=2]
add path null unhide
add path zero unhide
As far as we know, there is no reason to not expose /dev/crypto in jails so code in there can take advantage of hardware assisted crypto.
2003-09-26 10:32:21 +00:00
add path crypto unhide
Add a general mechanism for creating and applying devfs(8) rules in rc(8). It is most useful for applying rules to devfs(5) mount points in /dev or inside jails. The following line of script is sufficient to mount a relatively useful+secure devfs(5) in a jail: devfs_mount_jail /some/jail/dev Some new shell routines available to scripts that source rc.subr(5): o devfs_link - Makes it a little easier to create symlinks o devfs_init_rulesets - Create devfs(8) rulesets from devfs.rules o devfs_set_ruleset - Set a ruleset to a devfs(5) mount o devfs_apply_ruleset - Apply a ruleset to a devfs(5) mount o devfs_domount - Mount devfs(5) and apply some ruleset o devfs_mount_jail - Mount devfs(5) and apply a ruleset appropriate to jails. Additional rulesets can be specified in /etc/devfs.rules. If the devfs_system_ruleset variable is defined in rc.conf and it contains the name of a ruleset defined in /etc/defaults/devfs.rules or user supplied rulesets in /etc/devfs.rules then that ruleset will be applied to /dev at startup by the /etc/rc.d/devfs script. It can also be applied post-startup: /etc/rc.d/devfs start This is a more flexible mechanism than the previous method of using /etc/devfs.conf. However, that method is still available. Note: since devfs(8) doesn't provide any way for creating symlinks as part of a ruleset, anyone wishing to create symlinks in a devfs(5) as part of the bootup sequence will still have to rely on /etc/devfs.conf.
2003-08-20 06:15:18 +00:00
add path random unhide
add path urandom unhide
# Devices typically needed to support logged-in users.
# Requires: devfsrules_hide_all
#
[devfsrules_unhide_login=3]
add path 'ptyp*' unhide
add path 'ptyq*' unhide
add path 'ptyr*' unhide
add path 'ptys*' unhide
add path 'ptyP*' unhide
add path 'ptyQ*' unhide
add path 'ptyR*' unhide
add path 'ptyS*' unhide
Expose the upper 256 ptys in the default devfs rules. I should have updated this when expanding the old pty(4) driver to use 512 ptys by default. This is more important for 7.x. MFC after: 1 week
2010-01-04 18:21:27 +00:00
add path 'ptyl*' unhide
add path 'ptym*' unhide
add path 'ptyn*' unhide
add path 'ptyo*' unhide
add path 'ptyL*' unhide
add path 'ptyM*' unhide
add path 'ptyN*' unhide
add path 'ptyO*' unhide
Add a general mechanism for creating and applying devfs(8) rules in rc(8). It is most useful for applying rules to devfs(5) mount points in /dev or inside jails. The following line of script is sufficient to mount a relatively useful+secure devfs(5) in a jail: devfs_mount_jail /some/jail/dev Some new shell routines available to scripts that source rc.subr(5): o devfs_link - Makes it a little easier to create symlinks o devfs_init_rulesets - Create devfs(8) rulesets from devfs.rules o devfs_set_ruleset - Set a ruleset to a devfs(5) mount o devfs_apply_ruleset - Apply a ruleset to a devfs(5) mount o devfs_domount - Mount devfs(5) and apply some ruleset o devfs_mount_jail - Mount devfs(5) and apply a ruleset appropriate to jails. Additional rulesets can be specified in /etc/devfs.rules. If the devfs_system_ruleset variable is defined in rc.conf and it contains the name of a ruleset defined in /etc/defaults/devfs.rules or user supplied rulesets in /etc/devfs.rules then that ruleset will be applied to /dev at startup by the /etc/rc.d/devfs script. It can also be applied post-startup: /etc/rc.d/devfs start This is a more flexible mechanism than the previous method of using /etc/devfs.conf. However, that method is still available. Note: since devfs(8) doesn't provide any way for creating symlinks as part of a ruleset, anyone wishing to create symlinks in a devfs(5) as part of the bootup sequence will still have to rely on /etc/devfs.conf.
2003-08-20 06:15:18 +00:00
add path 'ttyp*' unhide
add path 'ttyq*' unhide
add path 'ttyr*' unhide
add path 'ttys*' unhide
add path 'ttyP*' unhide
add path 'ttyQ*' unhide
add path 'ttyR*' unhide
add path 'ttyS*' unhide
Expose the upper 256 ptys in the default devfs rules. I should have updated this when expanding the old pty(4) driver to use 512 ptys by default. This is more important for 7.x. MFC after: 1 week
2010-01-04 18:21:27 +00:00
add path 'ttyl*' unhide
add path 'ttym*' unhide
add path 'ttyn*' unhide
add path 'ttyo*' unhide
add path 'ttyL*' unhide
add path 'ttyM*' unhide
add path 'ttyN*' unhide
add path 'ttyO*' unhide
Integrate the new MPSAFE TTY layer to the FreeBSD operating system. The last half year I've been working on a replacement TTY layer for the FreeBSD kernel. The new TTY layer was designed to improve the following: - Improved driver model: The old TTY layer has a driver model that is not abstract enough to make it friendly to use. A good example is the output path, where the device drivers directly access the output buffers. This means that an in-kernel PPP implementation must always convert network buffers into TTY buffers. If a PPP implementation would be built on top of the new TTY layer (still needs a hooks layer, though), it would allow the PPP implementation to directly hand the data to the TTY driver. - Improved hotplugging: With the old TTY layer, it isn't entirely safe to destroy TTY's from the system. This implementation has a two-step destructing design, where the driver first abandons the TTY. After all threads have left the TTY, the TTY layer calls a routine in the driver, which can be used to free resources (unit numbers, etc). The pts(4) driver also implements this feature, which means posix_openpt() will now return PTY's that are created on the fly. - Improved performance: One of the major improvements is the per-TTY mutex, which is expected to improve scalability when compared to the old Giant locking. Another change is the unbuffered copying to userspace, which is both used on TTY device nodes and PTY masters. Upgrading should be quite straightforward. Unlike previous versions, existing kernel configuration files do not need to be changed, except when they reference device drivers that are listed in UPDATING. Obtained from: //depot/projects/mpsafetty/... Approved by: philip (ex-mentor) Discussed: on the lists, at BSDCan, at the DevSummit Sponsored by: Snow B.V., the Netherlands dcons(4) fixed by: kan
2008-08-20 08:31:58 +00:00
add path ptmx unhide
add path pts unhide
Add pts/pty to the un-hidden devices for logins. This un-breaks logins to jailed environments when the system is using PTS style ptys (kern.pts.enable=1). Discussed with: rwatson MFc after: 1 week
2007-10-12 14:55:41 +00:00
add path 'pts/*' unhide
If we're going to "add path 'fd/*' unhide", it only makes sense to "add path fd unhide" first. Requested by: mtm Approved by: rwatson (mentor)
2004-01-22 20:53:15 +00:00
add path fd unhide
Add a general mechanism for creating and applying devfs(8) rules in rc(8). It is most useful for applying rules to devfs(5) mount points in /dev or inside jails. The following line of script is sufficient to mount a relatively useful+secure devfs(5) in a jail: devfs_mount_jail /some/jail/dev Some new shell routines available to scripts that source rc.subr(5): o devfs_link - Makes it a little easier to create symlinks o devfs_init_rulesets - Create devfs(8) rulesets from devfs.rules o devfs_set_ruleset - Set a ruleset to a devfs(5) mount o devfs_apply_ruleset - Apply a ruleset to a devfs(5) mount o devfs_domount - Mount devfs(5) and apply some ruleset o devfs_mount_jail - Mount devfs(5) and apply a ruleset appropriate to jails. Additional rulesets can be specified in /etc/devfs.rules. If the devfs_system_ruleset variable is defined in rc.conf and it contains the name of a ruleset defined in /etc/defaults/devfs.rules or user supplied rulesets in /etc/devfs.rules then that ruleset will be applied to /dev at startup by the /etc/rc.d/devfs script. It can also be applied post-startup: /etc/rc.d/devfs start This is a more flexible mechanism than the previous method of using /etc/devfs.conf. However, that method is still available. Note: since devfs(8) doesn't provide any way for creating symlinks as part of a ruleset, anyone wishing to create symlinks in a devfs(5) as part of the bootup sequence will still have to rely on /etc/devfs.conf.
2003-08-20 06:15:18 +00:00
add path 'fd/*' unhide
add path stdin unhide
add path stdout unhide
add path stderr unhide
# Devices usually found in a jail.
#
[devfsrules_jail=4]
add include $devfsrules_hide_all
add include $devfsrules_unhide_basic
add include $devfsrules_unhide_login
Allow mounting FUSE filesystems in jails Reviewed by: jamie MFC after: 2 weeks Relnotes: yes Differential Revision: https://reviews.freebsd.org/D16371
2018-07-20 21:35:31 +00:00
add path fuse unhide
Unhide /dev/zfs in devfsrules_jail. The /dev/zfs device is required for managing jailed ZFS datasets. Discussed with: pjd, jamie MFC after: 1 week
2012-03-16 21:30:26 +00:00
add path zfs unhide
devfs.rules: unhide pf in vnet jails /dev/pf is usable in vnet jails, so don't hide the node there. We shouldn't expose /dev/pf in regular jails, as that gives them control over the host (or parent vnet jail) firewall. Reviewed by: bz Differential Revision: https://reviews.freebsd.org/D26537
2020-10-05 19:26:54 +00:00
[devfsrules_jail_vnet=5]
devfs.rules: Correctly unhide pf in vnet jails Revision 9e9be081d8 introduced a new devfs rule devfsrules_jail_vnet. It includes rule devfsrules_jail which include other rules. Unfortunately devfs could not recursively parse the action include and thus devfsrules_jail_vnet will expose all nodes. PR: 255660 Reviewed by: kp Obtained from: Gijs Peskens <gijs@peskens.net> MFC after: 3 weeks Differential Revision: https://reviews.freebsd.org/D32814
2021-11-03 11:46:48 +00:00
add include $devfsrules_hide_all
add include $devfsrules_unhide_basic
add include $devfsrules_unhide_login
devfs.rules: unhide pf in vnet jails /dev/pf is usable in vnet jails, so don't hide the node there. We shouldn't expose /dev/pf in regular jails, as that gives them control over the host (or parent vnet jail) firewall. Reviewed by: bz Differential Revision: https://reviews.freebsd.org/D26537
2020-10-05 19:26:54 +00:00
add include $devfsrules_jail
add path pf unhide
Reference in New Issue Copy Permalink