Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Video group grants access to two distinct hardware categories #268

Open
WhyNotHugo opened this issue Oct 25, 2023 · 3 comments
Open

Video group grants access to two distinct hardware categories #268

WhyNotHugo opened this issue Oct 25, 2023 · 3 comments

Comments

@WhyNotHugo
Copy link

There are two distinct sets of hardware that are owned by group video:

  • Video rendering devices (e.g.: drm).
  • Video input devices (e.g.: webcams).

On a typical Wayland setup, a dedicated daemon arbitrates access to video rendering devices (e.g.: seatd) and allows only a single process (generally a compositor) to access the hardware. Other processes are denied access to the video rendering hardware.

This is considered a security measure, and prevents arbitrary user processes from screen-scraping, or screen-spoofing.

However, in order to use a webcam, a user must be a member of the video group, which breaks the above security measure entirely.

I believe that one potential fix for this to change the ownership of webcams to the camera group. This is, however, a breaking changing where all downstreams will need to adapt.

@WhyNotHugo
Copy link
Author

WhyNotHugo commented Oct 25, 2023

Relevant rules are here:

SUBSYSTEM=="video4linux", GROUP="video"
SUBSYSTEM=="graphics", GROUP="video"
SUBSYSTEM=="drm", KERNEL!="renderD*", GROUP="video"
SUBSYSTEM=="dvb", GROUP="video"
SUBSYSTEM=="media", GROUP="video"
SUBSYSTEM=="cec", GROUP="video"

@bbonev
Copy link
Member

bbonev commented Oct 28, 2023

I think that the best way for this is to get it adopted downstream.
Starting from eudev will only bring breakage and confusion.
And after getting it adopted in distributions, we can include it in eudev upstream.
Did you work with a distribution that uses eudev regarding this change?

@WhyNotHugo
Copy link
Author

WhyNotHugo commented Oct 29, 2023

I've proposed addressing this on the Alpine side as well. I think that before actually proceeding there needs to be some consensus that my suggestd approach is okay on all sides.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants