IF YOU WOULD LIKE TO GET AN ACCOUNT, please write an
email to Administrator. User accounts are meant only to access repo
and report issues and/or generate pull requests.
This is a purpose-specific Git hosting for
BaseALT
projects. Thank you for your understanding!
Только зарегистрированные пользователи имеют доступ к сервису!
Для получения аккаунта, обратитесь к администратору.
Current wine is using /dev/sgX to access CD-ROM devices. Since
distributions switched to using ACL instead of group membership
to control device access, wine is not able to access them.
Add ACL to device nodes that already get GROUP="cdrom".
Ref: https://qa.mandriva.com/show_bug.cgi?id=62114
Signed-off-by: Andrey Borzenkov <arvidjaar@mail.ru>
Originally we added an ACL for some particular mobile phone product IDs to
enable users to run e. g. the Android SDK as non-root. This was removed in
232f180 as we don't want to maintain product/vendor ID lists in udev.
However, we already know from media-player-info that devices like this are
media players. There is little reason to deny user access to those, so add back
a generic rule which adds an ACL to media player raw USB devices.
https://launchpad.net/bugs/316215
DDC_DEVICEs are control points for high-end monitors such as the
HP DreamColor. The DDC/CI interface allows userspace applications
to upload custom colorspaces and interact with the display without
using the monitor hardware controls.
We should do only do classes of devices, not individual pieces
of hardware.
There is no way for us to manage this in the long term, and it needs
to be thought through what we want here, but it surely isn't a list of
smartphones in the udev source tarball installed on all systems.
When a custom rule sets ACL_MANAGE to 0 to disable ACL management for a
particular device, handle this as "disabled", by explicitly checking against
"1" instead of "nonempty".
Thanks to Rafał Rzepecki for pointing this out.
There doesn't seem to be any special class for their developer
interface, so match by Vendor and Device id like we do for things
like fingerprint readers.
This is better than their current 0666 suggestion <g>
Signed-off-by: Scott James Remnant <scott@ubuntu.com>
hplip tools need user access to the devices for checking ink levels and
user-level configuration. This was formerly done with hal FDIs.
As per discussion with Till Kamppeter.
