Udev rules installed by primesense allow public access to devices. They should be treated as any other input device instead, and the users logged into a specific seat should be allowed to access them, by using the uaccess TAG. See /usr/lib/udev/rules.d/70-uaccess.rules for some examples. Also, /etc/udev/rules.d is administrator territory. Please move the rules file to /usr/lib/udev/rules.d (aka %{_udevrulesdir}). Version-Release number of selected component (if applicable): openni-primesense-5.1.6.6-4.fc23.x86_64
(In reply to Zbigniew Jędrzejewski-Szmek from comment #0) > Udev rules installed by primesense allow public access to devices. They > should be treated as any other input device instead, and the users logged > into a specific seat should be allowed to access them, by using the uaccess > TAG. See /usr/lib/udev/rules.d/70-uaccess.rules for some examples. The primesense sensors aren't really normal input devices like webcams. Common use cases for these RGBD sensors include use in embedded robotic systems, where the sensor is accessed by a daemon (sometimes non-root) and there is no user logged in. I guess they're more similar to tv capture cards in that respect, which I do see mentioned in the 70-uaccess.rules. As the udev rule stands now, I would agree that 0664 or 0660 might be a better choice than the default 0666, so that at least the access is restricted to the "video" group instead of public r/w. As far as adding a uaccess tag, I have no idea what the "uaccess" tag does, or whether or not it would work in place of the existing rules for non-root daemon access. The udev manpage is no help, and google only turns up mentions of it; no definitive documentation at all. Is there somewhere I can find all of this out that I'm missing? > > Also, /etc/udev/rules.d is administrator territory. Please move the rules > file to /usr/lib/udev/rules.d (aka %{_udevrulesdir}). > While I don't disagree, is there a packaging guideline for this? Or a spec file snippet example? I don't see any of those. I also don't see any documentation or mention of the %{_udevrulesdir} macro in the packaging guidelines (or anywhere on the fedoraproject wiki for that matter,) and am therefore not sure if or how I was supposed to know about it.
(In reply to Rich Mattes from comment #1) > > Also, /etc/udev/rules.d is administrator territory. Please move the rules > > file to /usr/lib/udev/rules.d (aka %{_udevrulesdir}). > > While I don't disagree, is there a packaging guideline for this? Or a spec > file snippet example? I don't see any of those. I also don't see any > documentation or mention of the %{_udevrulesdir} macro in the packaging > guidelines (or anywhere on the fedoraproject wiki for that matter,) and am > therefore not sure if or how I was supposed to know about it. Indeed, it's not documented in Fedora guidelines. But it's documented in udev documentation [1]. I don't think you were *supposed* to know it, I certainly wasn't implying that. Udev rules were stored in /etc for many years, but over the last few years all systemd configuration shipped as part of the system has been moved to /usr. [1] http://www.freedesktop.org/software/systemd/man/udev.html#Rules%20Files > (In reply to Zbigniew Jędrzejewski-Szmek from comment #0) > > Udev rules installed by primesense allow public access to devices. They > > should be treated as any other input device instead, and the users logged > > into a specific seat should be allowed to access them, by using the uaccess > > TAG. See /usr/lib/udev/rules.d/70-uaccess.rules for some examples. > > The primesense sensors aren't really normal input devices like webcams. > Common use cases for these RGBD sensors include use in embedded robotic > systems, where the sensor is accessed by a daemon (sometimes non-root) and > there is no user logged in. I guess they're more similar to tv capture > cards in that respect, which I do see mentioned in the 70-uaccess.rules. > > As the udev rule stands now, I would agree that 0664 or 0660 might be a > better choice than the default 0666, so that at least the access is > restricted to the "video" group instead of public r/w. Yes, so there are three way lock down access to the device: 1. use the video group with 0660 mode 2. use a custom group with 0660 mode 3. make the device part of the seat, i.e. use the uaccess tag (but see below). In cases 1. and 2., the administrator adds the user the daemon is running under to the group to allow it constant access to the device. In case 3., the user that is currently logged in gets access to the device. From what you're writing it seems option 3. is not really applicable in this case. I think you should consider taking option 2. Basically, you can create a custom system group in %post, and document that the right user has to be added to that group. > As far as adding a uaccess tag, I have no idea what the "uaccess" tag does, > or whether or not it would work in place of the existing rules for non-root > daemon access. The udev manpage is no help, and google only turns up > mentions of it; no definitive documentation at all. Is there somewhere I > can find all of this out that I'm missing? You're right. I'm sorry, my description was very imprecise. Afaik, this isn't really documented anywhere. The process is done in two parts: 1. some package ships rules which set some udev variable on the devices (for example ENV{ID_SOFTWARE_RADIO}="label") 2. 70-uaccess.rules as shipped by systemd has a matching line which adds the uaccess tag based on this variable (ENV{ID_SOFTWARE_RADIO}=="?*", TAG+="uaccess"). So if primesense devices would fit one of the existing groups which already have their variables (ID_SOFTWARE_RADIO, ID_MEDIA_PLAYER, COLOR_MEASUREMENT_DEVICE, ID_INPUT_JOYSTICK, etc), then your rules could make use of that variable. Otherwise, a new variable would be added upstream.
This bug appears to have been reported against 'rawhide' during the Fedora 23 development cycle. Changing version to '23'. (As we did not run this process for some time, it could affect also pre-Fedora 23 development cycle bugs. We are very sorry. It will help us with cleanup during Fedora 23 End Of Life. Thank you.) More information and reason for this action is here: https://fedoraproject.org/wiki/BugZappers/HouseKeeping/Fedora23
This message is a reminder that Fedora 23 is nearing its end of life. Approximately 4 (four) weeks from now Fedora will stop maintaining and issuing updates for Fedora 23. It is Fedora's policy to close all bug reports from releases that are no longer maintained. At that time this bug will be closed as EOL if it remains open with a Fedora 'version' of '23'. Package Maintainer: If you wish for this bug to remain open because you plan to fix it in a currently maintained version, simply change the 'version' to a later Fedora version. Thank you for reporting this issue and we are sorry that we were not able to fix it before Fedora 23 is end of life. If you would still like to see this bug fixed and are able to reproduce it against a later version of Fedora, you are encouraged change the 'version' to a later Fedora version prior this bug is closed as described in the policy above. Although we aim to fix as many bugs as possible during every release's lifetime, sometimes those efforts are overtaken by events. Often a more recent Fedora release includes newer upstream software that fixes bugs or makes them obsolete.
This bug appears to have been reported against 'rawhide' during the Fedora 26 development cycle. Changing version to '26'.
This message is a reminder that Fedora 26 is nearing its end of life. Approximately 4 (four) weeks from now Fedora will stop maintaining and issuing updates for Fedora 26. It is Fedora's policy to close all bug reports from releases that are no longer maintained. At that time this bug will be closed as EOL if it remains open with a Fedora 'version' of '26'. Package Maintainer: If you wish for this bug to remain open because you plan to fix it in a currently maintained version, simply change the 'version' to a later Fedora version. Thank you for reporting this issue and we are sorry that we were not able to fix it before Fedora 26 is end of life. If you would still like to see this bug fixed and are able to reproduce it against a later version of Fedora, you are encouraged change the 'version' to a later Fedora version prior this bug is closed as described in the policy above. Although we aim to fix as many bugs as possible during every release's lifetime, sometimes those efforts are overtaken by events. Often a more recent Fedora release includes newer upstream software that fixes bugs or makes them obsolete.
Fedora 26 changed to end-of-life (EOL) status on 2018-05-29. Fedora 26 is no longer maintained, which means that it will not receive any further security or bug fix updates. As a result we are closing this bug. If you can reproduce this bug against a currently maintained version of Fedora please feel free to reopen this bug against that version. If you are unable to reopen this bug, please file a new report against the current release. If you experience problems, please add a comment to this bug. Thank you for reporting this bug and we are sorry it could not be fixed.