2020-11-09 07:23:58 +03:00
# SPDX-License-Identifier: LGPL-2.1-or-later
2017-11-18 20:18:16 +03:00
#
2011-05-26 04:21:16 +04:00
# This file is part of systemd.
#
# systemd is free software; you can redistribute it and/or modify it
2012-04-12 02:20:58 +04:00
# under the terms of the GNU Lesser General Public License as published by
# the Free Software Foundation; either version 2.1 of the License, or
2011-05-26 04:21:16 +04:00
# (at your option) any later version.
ACTION=="remove", GOTO="uaccess_end"
ENV{MAJOR}=="", GOTO="uaccess_end"
# PTP/MTP protocol devices, cameras, portable media players
SUBSYSTEM=="usb", ENV{ID_USB_INTERFACES}=="*:060101:*", TAG+="uaccess"
# Digicams with proprietary protocol
2014-07-15 04:04:47 +04:00
ENV{ID_GPHOTO2}=="?*", TAG+="uaccess"
2011-05-26 04:21:16 +04:00
# SCSI and USB scanners
ENV{libsane_matched}=="yes", TAG+="uaccess"
# HPLIP devices (necessary for ink level check and HP tool maintenance)
ENV{ID_HPLIP}=="1", TAG+="uaccess"
# optical drives
SUBSYSTEM=="block", ENV{ID_CDROM}=="1", TAG+="uaccess"
SUBSYSTEM=="scsi_generic", SUBSYSTEMS=="scsi", ATTRS{type}=="4|5", TAG+="uaccess"
# Sound devices
2018-02-23 18:49:17 +03:00
SUBSYSTEM=="sound", TAG+="uaccess", \
2013-07-07 20:32:34 +04:00
OPTIONS+="static_node=snd/timer", OPTIONS+="static_node=snd/seq"
2011-05-26 04:21:16 +04:00
# Webcams, frame grabber, TV cards
SUBSYSTEM=="video4linux", TAG+="uaccess"
SUBSYSTEM=="dvb", TAG+="uaccess"
2021-10-26 12:57:30 +03:00
SUBSYSTEM=="media", TAG+="uaccess"
2011-05-26 04:21:16 +04:00
2021-05-05 17:10:29 +03:00
# industrial cameras, some webcams, camcorders, set-top boxes, TV sets, audio devices, and more
hwdb: add hardware database for unit of IEEE 1394
Current udev rules configures group owner of firewire character device
to video group, corresponding to nodes in IEEE 1394 in below cases:
1.the node with any unit for any minor version of IIDC version 1
specification defined by 1394 Trading Association
2.the node with any unit for specification defined by Point Grey Research
3.the node with any unit for AV/C device v1.0 defined by 1394 Trading
Association
4.the node with any unit for vendor-unique protocol defined by 1394
Trading Association
Nevertheless, case 3 and 4 can cover the node with any unit for audio
function as well. In the cases, it's convenient to assign audio group.
Additionally, some nodes are known to have layout different from
the specification defined by 1394 Trading Association. In the case,
it's required to add rules specific to them.
Furthermore, some nodes have no fields for vendor name and model name in
configuration ROM. In the case, it's required to add entries to hardware
database for users convenience.
For the above reasons, this commit adds rules to use information in
hardware database for known units in IEEE 1394. One database entry
corresponds to one unit. Two types of key are used to match the unit;
customized key from node context, kernel modalias of unit context.
The entry has the type of function, at least. Supplementally, it has
vendor and model names.
For your information, below statements with Python pyparsing module are
expected to parse all of the custom key and module alias in the list:
```
subsystem_prefix = pp.Literal('ieee1394:').suppress()
hex_to_int = lambda a: int(a[0], 16)
node_prefix = pp.Literal('node:').suppress()
prefixed_lower_hex = pp.Combine(pp.Literal('0x') + pp.Word(pp.srange('[a-z0-9]'), exact=6)).setParseAction(hex_to_int)
ven_in_node = pp.dictOf(pp.Literal('ven'), prefixed_lower_hex)
mo_in_node = pp.dictOf(pp.Literal('mo'), prefixed_lower_hex)
unit_in_node = pp.Group(prefixed_lower_hex + pp.Literal(':').suppress() + prefixed_lower_hex)
units_in_node = pp.Group(pp.Literal('units') + pp.ZeroOrMore(pp.Literal('*')).suppress() + unit_in_node + pp.ZeroOrMore(pp.Literal('*')).suppress())
node_parser = subsystem_prefix + node_prefix + ven_in_node + pp.Optional(mo_in_node) + units_in_node
higher_hex = pp.Word(pp.srange('[A-Z0-9]'), exact=8).setParseAction(hex_to_int)
ven_in_unit = pp.dictOf(pp.Literal('ven'), higher_hex)
mo_literal_in_unit = pp.dictOf(pp.Literal('mo'), higher_hex)
mo_in_unit = pp.dictOf(pp.Literal('mo'), higher_hex ^ pp.Literal('*'))
sp_in_unit = pp.dictOf(pp.Literal('sp'), higher_hex)
ver_in_unit = pp.dictOf(pp.Literal('ver'), higher_hex)
unit_parser = subsystem_prefix + ven_in_unit + mo_in_unit + sp_in_unit + ver_in_unit
key_parser = node_parser ^ unit_parser
```
Signed-off-by: Takashi Sakamoto <o-takashi@sakamocchi.jp>
2021-04-07 05:49:22 +03:00
SUBSYSTEM=="firewire", TEST=="units", ENV{IEEE1394_UNIT_FUNCTION_MIDI}=="1", TAG+="uaccess"
SUBSYSTEM=="firewire", TEST=="units", ENV{IEEE1394_UNIT_FUNCTION_AUDIO}=="1", TAG+="uaccess"
SUBSYSTEM=="firewire", TEST=="units", ENV{IEEE1394_UNIT_FUNCTION_VIDEO}=="1", TAG+="uaccess"
Revert "rules: allow users to access frame buffer devices" (#3333)
This reverts commit 483d8bbb4c0190f419bf9fba57fb0feb1a56bea6.
In [1] Michel Dänzer and Daniel Vetter wrote:
>> The scenario you describe isn't possible if the Wayland compositor
>> directly uses the KMS API of /dev/dri/card*, but it may be possible if
>> the Wayland compositor uses the fbdev API of /dev/fb* instead (e.g. if
>> weston uses its fbdev backend).
>
> Yeah, if both weston and your screen grabber uses native fbdev API you can
> now screenshot your desktop. And since fbdev has no concept of "current
> owner of the display hw" like the drm master, I think this is not fixable.
> At least not just in userspace. Also even with native KMS compositors
> fbdev still doesn't have the concept of ownership, which is why it doesn't
> bother clearing it's buffer before KMS takes over. I agree that this
> should be reverted or at least hidden better.
TBH, I think that privilege separation between processes running under the same
UID is tenuous. Even with drm, in common setups any user process can ptrace the
"current owner of the display" and call DROP_MASTER or do whatever. It *is*
possible to prevent that, e.g. by disabling ptrace using yama.ptrace_scope, or
selinux, and so on, but afaik this is not commonly done. E.g. all Fedora
systems pull in elfutils-default-yama-scope.rpm through dependencies which sets
yama.ptrace_scope=0. And even assuming that ptrace was disabled, it is trivial
to modify files on disk, communicate through dbus, etc; there is just to many
ways for a non-sandboxed process to interact maliciously with the display shell
to close them all off. To achieve real protection, some sort of sandboxing
must be implemented, and in that case there is no need to rely on access mode
on the device files, since much more stringent measures have to be implemented
anyway.
The situation is similar for framebuffer devices. It is common to add
framebuffer users to video group to allow them unlimited access to /dev/fb*.
Using uaccess would be better solution in that case. Also, since there is no
"current owner" limitation like in DRM, processes running under the same UID
should be able to access /proc/<pid-of-display-server>/fd/* and gain access to
the devices. Nevertheless, weston implements a suid wrapper to access the
devices and then drop privileges, and this patch would make this daemon
pointless. So if the weston developers feel that this change reduces security,
I prefer to revert it.
[1] https://lists.freedesktop.org/archives/wayland-devel/2016-May/029017.html
2016-05-24 12:32:30 +03:00
# DRI video devices
2017-10-31 18:46:24 +03:00
SUBSYSTEM=="drm", KERNEL=="card*", TAG+="uaccess"
2021-05-16 14:57:00 +03:00
{% if GROUP_RENDER_UACCESS %}
2019-03-14 01:22:26 +03:00
# DRI render nodes
2021-05-16 14:57:00 +03:00
SUBSYSTEM=="drm", KERNEL=="renderD*", TAG+="uaccess"
{% endif %}
{% if DEV_KVM_UACCESS %}
2018-07-10 15:47:58 +03:00
# KVM
2021-05-16 14:57:00 +03:00
SUBSYSTEM=="misc", KERNEL=="kvm", TAG+="uaccess"
{% endif %}
2018-07-10 15:47:58 +03:00
2011-05-26 04:21:16 +04:00
# smart-card readers
2014-07-15 04:04:47 +04:00
ENV{ID_SMARTCARD_READER}=="?*", TAG+="uaccess"
2011-05-26 04:21:16 +04:00
2012-07-24 22:13:46 +04:00
# (USB) authentication devices
2014-07-15 04:04:47 +04:00
ENV{ID_SECURITY_TOKEN}=="?*", TAG+="uaccess"
2012-07-24 22:13:46 +04:00
2011-05-26 04:21:16 +04:00
# PDA devices
2014-07-15 04:04:47 +04:00
ENV{ID_PDA}=="?*", TAG+="uaccess"
2011-05-26 04:21:16 +04:00
# Programmable remote control
ENV{ID_REMOTE_CONTROL}=="1", TAG+="uaccess"
# joysticks
SUBSYSTEM=="input", ENV{ID_INPUT_JOYSTICK}=="?*", TAG+="uaccess"
# color measurement devices
2014-07-15 04:04:47 +04:00
ENV{COLOR_MEASUREMENT_DEVICE}=="?*", TAG+="uaccess"
2011-05-26 04:21:16 +04:00
# DDC/CI device, usually high-end monitors such as the DreamColor
2014-07-15 04:04:47 +04:00
ENV{DDC_DEVICE}=="?*", TAG+="uaccess"
2011-05-26 04:21:16 +04:00
# media player raw devices (for user-mode drivers, Android SDK, etc.)
SUBSYSTEM=="usb", ENV{ID_MEDIA_PLAYER}=="?*", TAG+="uaccess"
rules: uaccess - add ID_SOFTWARE_RADIO
On Tue, Jul 15, 2014 at 1:52 PM, Alick Zhao <alick9188@gmail.com> wrote:
>>>
>>> So maybe ID_SOFTWARE_RADIO ?
>>
>> Hmm, SDR is more a term for a generic technology than for a device
>> class. To me it does not really sound like an administrator would know
>> what this is.
>>
>> What exactly is the device or subsystem you want to make accessible to
>> locally logged-in users only?
>
> Initially it is bladeRF, but many more are of interest: USRP, rtl-sdr,
> HackRF, ... [1]
>
> I agree an administrator might not know what SDR is, since it is
> currently still not widely known, and makes sense only for amateurs
> and researchers. But as a SDR fan, I see many new SDR peripherals
> are created recently, and expect to see more. So a generic ID seems
> reasonable to me.
>
> [1] http://en.wikipedia.org/wiki/List_of_software-defined_radios
2014-07-15 19:35:53 +04:00
# software-defined radio communication devices
ENV{ID_SOFTWARE_RADIO}=="?*", TAG+="uaccess"
2016-03-15 16:25:51 +03:00
# 3D printers, CNC machines, laser cutters, 3D scanners, etc.
ENV{ID_MAKER_TOOL}=="?*", TAG+="uaccess"
2021-08-24 14:54:02 +03:00
# Protocol analyzers
ENV{ID_SIGNAL_ANALYZER}=="?*", ENV{DEVTYPE}=="usb_device", TAG+="uaccess"
2022-08-09 19:09:32 +03:00
ENV{ID_SIGNAL_ANALYZER}=="?*", KERNEL=="ttyACM[0-9]*", TAG+="uaccess"
2021-08-24 14:54:02 +03:00
2021-12-02 15:15:44 +03:00
# rfkill / radio killswitches
KERNEL=="rfkill", SUBSYSTEM=="misc", TAG+="uaccess"
2021-08-28 06:30:50 +03:00
# AV production controllers
# Most of these devices use HID for the knobs, faders, buttons, encoders, and jog wheels.
SUBSYSTEM=="hidraw", ENV{ID_AV_PRODUCTION_CONTROLLER}=="1", TAG+="uaccess"
# Some devices use vendor defined protocols on USB Bulk endpoints for controllers.
# Other devices transfer graphics to screens on the device through USB Bulk endpoints.
# This also allows accessing HID devices with the libusb backend of hidapi.
SUBSYSTEM=="usb", ENV{ID_AV_PRODUCTION_CONTROLLER}=="1", TAG+="uaccess"
2011-05-26 04:21:16 +04:00
LABEL="uaccess_end"