shaba/systemd
1
0
Fork 0
mirror of https://github.com/systemd/systemd.git synced 2024-11-05 06:52:22 +03:00
Code
a0693fc951
systemd/rules/50-udev-default.rules.in

82 lines
3.4 KiB
Plaintext
Raw Normal View History

rules: add default rules
2007-08-10 14:36:59 +04:00
# do not edit this file, it will be overwritten on update
rules: merge udev-late.rules files
2015-03-12 18:34:18 +03:00
# run a command on remove events
ACTION=="remove", ENV{REMOVE_CMD}!="", RUN+="$env{REMOVE_CMD}"
50-udev-default.rules: don't run anything but REMOVE_CMD on remove we don't want to run usb_id and input_id on ACTION=="remove"
2015-03-27 17:42:04 +03:00
ACTION=="remove", GOTO="default_end"
rules: merge udev-late.rules files
2015-03-12 18:34:18 +03:00
rules: move builtin calls before the permissions section <heftig> kay: systemd commit 22582bb broke cups usb printing for me <heftig> because the "lp" group isn't applied anymore <heftig> SUBSYSTEM=="usb", ENV{DEVTYPE}=="usb_device", ENV{ID_USB_INTERFACES}=="*:0701??:*", GROUP="lp" <heftig> moving this line to the end of 50-udev-default.rules restores correct behavior, as it's after usb_id
2013-03-20 04:26:17 +04:00
SUBSYSTEM=="virtio-ports", KERNEL=="vport*", ATTR{name}=="?*", SYMLINK+="virtio-ports/$attr{name}"
always unconditionally create /dev/rtc and use it internally Partially revert 2b3c81b02fa5dd47b19558c7684e113f36a48486, which tried to avoid inconsistent rules about when and how to create the /dev/rtc symlink. Instead of conditionally or not creating the /dev/rtc link at all, now always create it with additional and more reliable udev rules. First try to find the "system rtc" with the hctosys flag, if this is not found, fall back to create the link for /dev/rtc0. Our code now never actively searches for the "system rtc" it can always use /dev/rtc.
2013-04-25 04:02:40 +04:00
# select "system RTC" or just use the first one
SUBSYSTEM=="rtc", ATTR{hctosys}=="1", SYMLINK+="rtc"
SUBSYSTEM=="rtc", KERNEL=="rtc0", SYMLINK+="rtc", OPTIONS+="link_priority=-100"
rules: move builtin calls before the permissions section <heftig> kay: systemd commit 22582bb broke cups usb printing for me <heftig> because the "lp" group isn't applied anymore <heftig> SUBSYSTEM=="usb", ENV{DEVTYPE}=="usb_device", ENV{ID_USB_INTERFACES}=="*:0701??:*", GROUP="lp" <heftig> moving this line to the end of 50-udev-default.rules restores correct behavior, as it's after usb_id
2013-03-20 04:26:17 +04:00
SUBSYSTEM=="usb", ENV{DEVTYPE}=="usb_device", IMPORT{builtin}="usb_id", IMPORT{builtin}="hwdb --subsystem=usb"
SUBSYSTEM=="input", ENV{ID_INPUT}=="", IMPORT{builtin}="input_id"
ENV{MODALIAS}!="", IMPORT{builtin}="hwdb --subsystem=$env{SUBSYSTEM}"
rules: merge udev-late.rules files
2015-03-12 18:34:18 +03:00
ACTION!="add", GOTO="default_end"
udev: set default rules permissions only at "add" events
2013-01-28 00:46:36 +04:00
udev: update some rules
2012-04-15 16:06:48 +04:00
SUBSYSTEM=="tty", KERNEL=="ptmx", GROUP="tty", MODE="0666"
SUBSYSTEM=="tty", KERNEL=="tty", GROUP="tty", MODE="0666"
SUBSYSTEM=="tty", KERNEL=="tty[0-9]*", GROUP="tty", MODE="0620"
udev/rules: setup tty permissions and group for sclp_line, ttysclp and 3270/tty
2014-02-27 14:19:09 +04:00
SUBSYSTEM=="tty", KERNEL=="sclp_line[0-9]*", GROUP="tty", MODE="0620"
SUBSYSTEM=="tty", KERNEL=="ttysclp[0-9]*", GROUP="tty", MODE="0620"
SUBSYSTEM=="tty", KERNEL=="3270/tty[0-9]*", GROUP="tty", MODE="0620"
udev: update some rules
2012-04-15 16:06:48 +04:00
SUBSYSTEM=="vc", KERNEL=="vcs*|vcsa*", GROUP="tty"
rules: add rfcomm* to group dialout https://bugs.launchpad.net/bugs/368109
2009-04-28 13:24:25 +04:00
KERNEL=="tty[A-Z]*[0-9]|pppox[0-9]*|ircomm[0-9]*|noz[0-9]*|rfcomm[0-9]*", GROUP="dialout"
rules: add default rules
2007-08-10 14:36:59 +04:00
udev: update some rules
2012-04-15 16:06:48 +04:00
SUBSYSTEM=="mem", KERNEL=="mem|kmem|port", GROUP="kmem", MODE="0640"
rules: add default rules
2007-08-10 14:36:59 +04:00
udev: assign group "input" to all input devices
2014-06-12 16:59:53 +04:00
SUBSYSTEM=="input", GROUP="input"
rules: remove pointless MODE= settings Changing the default MODE= for the group accessi, but not specifying a GROUP= does not provide anything. It disables the default logic that the mode switches to 0660 as soon as a GROUP= is specifed, which make custom rules uneccesarily complicated. https://bugs.freedesktop.org/show_bug.cgi?id=70665
2013-10-21 05:49:03 +04:00
SUBSYSTEM=="input", KERNEL=="js[0-9]*", MODE="0664"
rules: add default rules
2007-08-10 14:36:59 +04:00
tabs are as useful as a hole in the head
2012-01-10 04:34:15 +04:00
SUBSYSTEM=="video4linux", GROUP="video"
SUBSYSTEM=="graphics", GROUP="video"
SUBSYSTEM=="drm", GROUP="video"
udev: set default rules permissions only at "add" events
2013-01-28 00:46:36 +04:00
SUBSYSTEM=="dvb", GROUP="video"
rules: add default rules
2007-08-10 14:36:59 +04:00
tabs are as useful as a hole in the head
2012-01-10 04:34:15 +04:00
SUBSYSTEM=="sound", GROUP="audio", \
rules: apply 'audio' group of the static snd/{seq,timer} nodes
2011-05-27 04:50:29 +04:00
OPTIONS+="static_node=snd/seq", OPTIONS+="static_node=snd/timer"
rules: drop almost all NAME= keys The drivers in kernel 2.6.31 supply the names for custom node names if needed.
2009-09-16 22:08:50 +04:00
udev: set default rules permissions only at "add" events
2013-01-28 00:46:36 +04:00
SUBSYSTEM=="usb", ENV{DEVTYPE}=="usb_device", MODE="0664"
rules: add default rules
2007-08-10 14:36:59 +04:00
rules: set group ownership of new firewire driver device files The newer firewire-core driver exposes per-device character device files, called /dev/fw[0-9]*, in contrast to the older raw1394, video1394, dv1394 drivers which created one global file or per-controller files. This allows to set ownership, permissions, or/ and access control lists for each device file based on device type markers obtained from sysfs. The "units" attribute which is used for this purpose has become available in Linux 2.6.31(-rc1) by commit 0210b66dd88a2a1e451901b00378a2068b6ccb35. The added rules match identifiers of - IIDC devices: industrial cameras and some webcams, - AV/C devices: camcorders, set-top boxes, TV sets, audio devices, and similar devices. Signed-off-by: Stefan Richter <stefanr@s5r6.in-berlin.de>
2009-07-01 23:41:43 +04:00
SUBSYSTEM=="firewire", ATTR{units}=="*0x00a02d:0x00010*", GROUP="video"
rules: add more FireWire IDs: Point Grey IIDC; AV/C + vendor unique 1. IIDC cameras from Point Grey use the vendor OUI as Specifier_ID instead of the 1394 TA's OUI but are otherwise fully compliant to the IIDC spec. Their device files should be accessible like those of any other IIDC cameras. 2. Originally, the Software_Version of devices that implement FCP (IEC 61883-1 Function Control Protocol) was meant to be a bitmap of all command sets that an FCP capable unit supports. Bitmap flags are defined for AV/C, CAL, EHS, HAVi, and vendor unique command sets. Software_Version was revised to be a simple identifier instead, and devices that support several command sets were meant to instantiate one unit directory for each command set. Still, some devices with the flags for AV/C and vendor unique command sets combined were released (but apparently no devices with any other flag combinations). These rare but existing AV/C + vendor unique devices need to be accessible just like plain AV/C devices. Side notes: - Many AV/C devices make use of the Vendor Dependent AV/C command, but this is unrelated to vendor unique FCP command sets. - Here are all standardized FireWire protocol identifiers that I know of, listed as Specifier_ID:Software_Version | specifier | protocol. 0x00005e:0x000001 | IANA | IPv4 over 1394 (RFC 2734) 0x00005e:0x000002 | IANA | IPv6 over 1394 (RFC 3146) 0x00609e:0x010483 | INCITS | SBP-2 (or SCSI command sets over SBP-3) 0x00609e:0x0105bb | INCITS | AV/C over SBP-3 0x00a02d:0x010001 | 1394 TA | AV/C (over FCP) 0x00a02d:0x010002 | 1394 TA | CAL 0x00a02d:0x010004 | 1394 TA | EHS 0x00a02d:0x010008 | 1394 TA | HAVi 0x00a02d:0x014000 | 1394 TA | Vendor Unique 0x00a02d:0x014001 | 1394 TA | Vendor Unique and AV/C (over FCP) 0x00a02d:0x000100 | 1394 TA | IIDC 1.04 0x00a02d:0x000101 | 1394 TA | IIDC 1.20 0x00a02d:0x000102 | 1394 TA | IIDC 1.30 0x00a02d:0x0A6BE2 | 1394 TA | DPP 1.0 0x00a02d:0x4B661F | 1394 TA | IICP 1.0 For now we are only interested in udev rules for AV/C and IIDC. Reported-by: Damien Douxchamps <ddsf@douxchamps.net> (Point Grey IIDC ID) Reported-by: Clemens Ladisch <clemens@ladisch.de> (AV/C + vendor unique ID) Signed-off-by: Stefan Richter <stefanr@s5r6.in-berlin.de>
2010-07-11 14:32:12 +04:00
SUBSYSTEM=="firewire", ATTR{units}=="*0x00b09d:0x00010*", GROUP="video"
rules: set group ownership of new firewire driver device files The newer firewire-core driver exposes per-device character device files, called /dev/fw[0-9]*, in contrast to the older raw1394, video1394, dv1394 drivers which created one global file or per-controller files. This allows to set ownership, permissions, or/ and access control lists for each device file based on device type markers obtained from sysfs. The "units" attribute which is used for this purpose has become available in Linux 2.6.31(-rc1) by commit 0210b66dd88a2a1e451901b00378a2068b6ccb35. The added rules match identifiers of - IIDC devices: industrial cameras and some webcams, - AV/C devices: camcorders, set-top boxes, TV sets, audio devices, and similar devices. Signed-off-by: Stefan Richter <stefanr@s5r6.in-berlin.de>
2009-07-01 23:41:43 +04:00
SUBSYSTEM=="firewire", ATTR{units}=="*0x00a02d:0x010001*", GROUP="video"
rules: add more FireWire IDs: Point Grey IIDC; AV/C + vendor unique 1. IIDC cameras from Point Grey use the vendor OUI as Specifier_ID instead of the 1394 TA's OUI but are otherwise fully compliant to the IIDC spec. Their device files should be accessible like those of any other IIDC cameras. 2. Originally, the Software_Version of devices that implement FCP (IEC 61883-1 Function Control Protocol) was meant to be a bitmap of all command sets that an FCP capable unit supports. Bitmap flags are defined for AV/C, CAL, EHS, HAVi, and vendor unique command sets. Software_Version was revised to be a simple identifier instead, and devices that support several command sets were meant to instantiate one unit directory for each command set. Still, some devices with the flags for AV/C and vendor unique command sets combined were released (but apparently no devices with any other flag combinations). These rare but existing AV/C + vendor unique devices need to be accessible just like plain AV/C devices. Side notes: - Many AV/C devices make use of the Vendor Dependent AV/C command, but this is unrelated to vendor unique FCP command sets. - Here are all standardized FireWire protocol identifiers that I know of, listed as Specifier_ID:Software_Version | specifier | protocol. 0x00005e:0x000001 | IANA | IPv4 over 1394 (RFC 2734) 0x00005e:0x000002 | IANA | IPv6 over 1394 (RFC 3146) 0x00609e:0x010483 | INCITS | SBP-2 (or SCSI command sets over SBP-3) 0x00609e:0x0105bb | INCITS | AV/C over SBP-3 0x00a02d:0x010001 | 1394 TA | AV/C (over FCP) 0x00a02d:0x010002 | 1394 TA | CAL 0x00a02d:0x010004 | 1394 TA | EHS 0x00a02d:0x010008 | 1394 TA | HAVi 0x00a02d:0x014000 | 1394 TA | Vendor Unique 0x00a02d:0x014001 | 1394 TA | Vendor Unique and AV/C (over FCP) 0x00a02d:0x000100 | 1394 TA | IIDC 1.04 0x00a02d:0x000101 | 1394 TA | IIDC 1.20 0x00a02d:0x000102 | 1394 TA | IIDC 1.30 0x00a02d:0x0A6BE2 | 1394 TA | DPP 1.0 0x00a02d:0x4B661F | 1394 TA | IICP 1.0 For now we are only interested in udev rules for AV/C and IIDC. Reported-by: Damien Douxchamps <ddsf@douxchamps.net> (Point Grey IIDC ID) Reported-by: Clemens Ladisch <clemens@ladisch.de> (AV/C + vendor unique ID) Signed-off-by: Stefan Richter <stefanr@s5r6.in-berlin.de>
2010-07-11 14:32:12 +04:00
SUBSYSTEM=="firewire", ATTR{units}=="*0x00a02d:0x014001*", GROUP="video"
rules: add default rules
2007-08-10 14:36:59 +04:00
tabs are as useful as a hole in the head
2012-01-10 04:34:15 +04:00
KERNEL=="parport[0-9]*", GROUP="lp"
SUBSYSTEM=="printer", KERNEL=="lp*", GROUP="lp"
SUBSYSTEM=="ppdev", GROUP="lp"
KERNEL=="lp[0-9]*", GROUP="lp"
KERNEL=="irlpt[0-9]*", GROUP="lp"
rules: fix wrong wildcard match, we always need a ':*' at the end
2011-07-05 07:37:13 +04:00
SUBSYSTEM=="usb", ENV{DEVTYPE}=="usb_device", ENV{ID_USB_INTERFACES}=="*:0701??:*", GROUP="lp"
rules: add default rules
2007-08-10 14:36:59 +04:00
rules: reorder block rules
2009-01-05 14:34:55 +03:00
SUBSYSTEM=="block", GROUP="disk"
rules: fix typo
2011-11-08 02:21:29 +04:00
SUBSYSTEM=="block", KERNEL=="sr[0-9]*", GROUP="cdrom"
rules: add SUBSYSTEM match to scsi rules On Fri, May 22, 2009 at 16:15, Alan Jenkins <alan-jenkins@tuffmail.co.uk> wrote: > I've been looking at what is responsible for all the path lookup activity in > coldplug. On my debian stable system, it looks like every device gets its > parent looked up in sysfs. I think this is due to SUBSYSTEMS matches. > > I see the udev default rules are different, but it looks like they still > test for SUBSYSTEMS on every single device. Should we add SUBSYSTEM="scsi_generic" > to these three rules?
2009-05-22 18:44:53 +04:00
SUBSYSTEM=="scsi_generic", SUBSYSTEMS=="scsi", ATTRS{type}=="4|5", GROUP="cdrom"
udev: update some rules
2012-04-15 16:06:48 +04:00
KERNEL=="sch[0-9]*", GROUP="cdrom"
rules: drop almost all NAME= keys The drivers in kernel 2.6.31 supply the names for custom node names if needed.
2009-09-16 22:08:50 +04:00
KERNEL=="pktcdvd[0-9]*", GROUP="cdrom"
KERNEL=="pktcdvd", GROUP="cdrom"
rules: Ubuntu merge - use group "tape"
2009-01-03 18:25:15 +03:00
rules: add SUBSYSTEM match to scsi rules On Fri, May 22, 2009 at 16:15, Alan Jenkins <alan-jenkins@tuffmail.co.uk> wrote: > I've been looking at what is responsible for all the path lookup activity in > coldplug. On my debian stable system, it looks like every device gets its > parent looked up in sysfs. I think this is due to SUBSYSTEMS matches. > > I see the udev default rules are different, but it looks like they still > test for SUBSYSTEMS on every single device. Should we add SUBSYSTEM="scsi_generic" > to these three rules?
2009-05-22 18:44:53 +04:00
SUBSYSTEM=="scsi_generic|scsi_tape", SUBSYSTEMS=="scsi", ATTRS{type}=="1|8", GROUP="tape"
SUBSYSTEM=="scsi_generic", SUBSYSTEMS=="scsi", ATTRS{type}=="0", GROUP="disk"
rules: add default rules
2007-08-10 14:36:59 +04:00
KERNEL=="qft[0-9]*|nqft[0-9]*|zqft[0-9]*|nzqft[0-9]*|rawqft[0-9]*|nrawqft[0-9]*", GROUP="disk"
rules: add loop-control and btrfs-control to "disk" group
2014-06-18 05:37:32 +04:00
KERNEL=="loop-control", GROUP="disk", OPTIONS+="static_node=loop-control"
KERNEL=="btrfs-control", GROUP="disk"
rules: drop almost all NAME= keys The drivers in kernel 2.6.31 supply the names for custom node names if needed.
2009-09-16 22:08:50 +04:00
KERNEL=="rawctl", GROUP="disk"
SUBSYSTEM=="raw", KERNEL=="raw[0-9]*", GROUP="disk"
SUBSYSTEM=="aoe", GROUP="disk", MODE="0220"
rules: move aoe rules to default rules file
2008-12-09 06:18:21 +03:00
SUBSYSTEM=="aoe", KERNEL=="err", MODE="0440"
rules: add default rules
2007-08-10 14:36:59 +04:00
rules: remove pointless MODE= settings Changing the default MODE= for the group accessi, but not specifying a GROUP= does not provide anything. It disables the default logic that the mode switches to 0660 as soon as a GROUP= is specifed, which make custom rules uneccesarily complicated. https://bugs.freedesktop.org/show_bug.cgi?id=70665
2013-10-21 05:49:03 +04:00
KERNEL=="rfkill", MODE="0664"
udev: set default rules permissions only at "add" events
2013-01-28 00:46:36 +04:00
KERNEL=="tun", MODE="0666", OPTIONS+="static_node=net/tun"
rules: add default rules
2007-08-10 14:36:59 +04:00
udev: set default rules permissions only at "add" events
2013-01-28 00:46:36 +04:00
KERNEL=="fuse", MODE="0666", OPTIONS+="static_node=fuse"
rules: mount fuse control filesystem
2010-05-25 17:10:21 +04:00
rules: add a rule to set /dev/kvm access mode and ownership (#5597) Kernel default mode is 0600, but distributions change it to group kvm, mode either 0660 (e.g. Debian) or 0666 (e.g. Fedora). Both approaches have valid reasons (a stricter mode limits exposure to bugs in the kvm subsystem, a looser mode makes libvirt and other virtualization mechanisms work out of the box for unprivileged users over ssh). In Fedora the qemu package carries the relevant rule, but it's nicer to have it in systemd, so that the permissions are not dependent on the qemu package being installed. Use of packaged qemu binaries is not required to make use of /dev/kvm, e.g. it's possible to use a self-compiled qemu or some alternative. https://bugzilla.redhat.com/show_bug.cgi?id=1431876 To accomodate both approaches, add a rule to set the mode in 50-udev-default.rules, but allow the mode to be overridden with a --with-dev-kvm-mode configure rule. The default is 0660, as the (slightly) more secure option.
2017-03-27 13:34:24 +03:00
KERNEL=="kvm", GROUP="kvm", MODE="@DEV_KVM_MODE@"
udev rules: add udev rule to create /dev/ptp_kvm (#5495) Its necessary to specify the KVM PTP device name in userspace. In case a network card with PTP device is assigned to the guest, it might be the case that KVM PTP gets /dev/ptp0 instead of /dev/ptp1. Fix a device name for the KVM PTP device.
2017-02-28 23:28:21 +03:00
SUBSYSTEM=="ptp", ATTR{clock_name}=="KVM virtual PTP", SYMLINK += "ptp_kvm"
rules: merge udev-late.rules files
2015-03-12 18:34:18 +03:00
LABEL="default_end"
Copy Permalink