The /dev/input/event* files are not accessible by users by default. However, some software relies on accessing these files, for example to access joystick devices. This is exactly what e.g. OIS (dev-games/ois-1.2.0) does. I'm not sure, but there may be other software out there that is also affected. I propose that event device files that do not refer to keyboard or pointer devices should not be owned by the group root, but by some other group to which users can be added if they should be able to get direct access (as it is the case with other device files already). Reproducible: Always Steps to Reproduce: Portage 2.2_rc14 (default/linux/amd64/2008.0, gcc-4.1.2, glibc-2.8_p20080602-r0, 2.6.25.9 x86_64) ================================================================= System uname: Linux-2.6.25.9-x86_64-AMD_Athlon-tm-_64_X2_Dual_Core_Processor_4200+-with-glibc2.2.5 Timestamp of tree: Fri, 14 Nov 2008 18:30:01 +0000 app-shells/bash: 3.2_p39 dev-java/java-config: 1.3.7, 2.1.6-r1 dev-lang/python: 2.4.4-r13, 2.5.2-r8 dev-python/pycrypto: 2.0.1-r6 dev-util/cmake: 2.6.2 sys-apps/baselayout: 2.0.0 sys-apps/openrc: 0.3.0-r1 sys-apps/sandbox: 1.2.18.1-r3 sys-devel/autoconf: 2.13, 2.63 sys-devel/automake: 1.5, 1.7.9-r1, 1.8.5-r3, 1.9.6-r2, 1.10.1-r1 sys-devel/binutils: 2.19 sys-devel/gcc-config: 1.4.0-r4 sys-devel/libtool: 2.2.6a virtual/os-headers: 2.6.27-r2 ACCEPT_KEYWORDS="amd64 ~amd64" CBUILD="x86_64-pc-linux-gnu" CFLAGS="-march=athlon64 -O2 -pipe" CHOST="x86_64-pc-linux-gnu" CONFIG_PROTECT="/etc /usr/share/config" CONFIG_PROTECT_MASK="/etc/ca-certificates.conf /etc/env.d /etc/env.d/java/ /etc/fonts/fonts.conf /etc/gconf /etc/gentoo-release /etc/terminfo /etc/texmf/web2c /etc/udev/rules.d" CXXFLAGS="-march=athlon64 -O2 -pipe" DISTDIR="/usr/portage/distfiles" FEATURES="distlocks parallel-fetch preserve-libs protect-owned sandbox sfperms strict unmerge-orphans userfetch" GENTOO_MIRRORS="http://linux.rz.ruhr-uni-bochum.de/download/gentoo-mirror/ ftp://linux.rz.ruhr-uni-bochum.de/gentoo-mirror/ " LDFLAGS="-Wl,-O1" MAKEOPTS="-j2" PKGDIR="/usr/portage/packages" PORTAGE_RSYNC_OPTS="--recursive --links --safe-links --perms --times --compress --force --whole-file --delete --stats --timeout=180 --exclude=/distfiles --exclude=/local --exclude=/packages" PORTAGE_TMPDIR="/var/tmp" PORTDIR="/usr/portage" SYNC="rsync://rsync.gentoo.org/gentoo-portage" USE="3dnow X a52 aac acl alsa amazon amd64 berkdb bluetooth bzip2 cdaudio cddb cdparanoia cdr cdrom cli cracklib crypt css cups cvs cxx dbus dga djvu dri dts dv dvd exif ffmpeg flac fontconfig fortran gdbm gif gpm hal iconv icq ipv6 isdnlog jabber jbig jpeg jpeg2k kde latex lcms midi mmx mudflap multilib ncurses nls nptl nptlonly ogg ogg123 openexr opengl openmp pam pcre pdf perl png pppd python readline reflection session smp spl sse sse2 ssl svg sysfs tcpd tiff unicode usb vnc vorbis wavpack xorg xulrunner zlib" ALSA_CARDS="ali5451 als4000 atiixp atiixp-modem bt87x ca0106 cmipci emu10k1x ens1370 ens1371 es1938 es1968 fm801 hda-intel intel8x0 intel8x0m maestro3 trident usb-audio via82xx via82xx-modem ymfpci" ALSA_PCM_PLUGINS="adpcm alaw asym copy dmix dshare dsnoop empty extplug file hooks iec958 ioplug ladspa lfloat linear meter mmap_emul mulaw multi null plug rate route share shm softvol" APACHE2_MODULES="actions alias auth_basic authn_alias authn_anon authn_dbm authn_default authn_file authz_dbm authz_default authz_groupfile authz_host authz_owner authz_user autoindex cache dav dav_fs dav_lock deflate dir disk_cache env expires ext_filter file_cache filter headers include info log_config logio mem_cache mime mime_magic negotiation rewrite setenvif speling status unique_id userdir usertrack vhost_alias" ELIBC="glibc" INPUT_DEVICES="wacom" KERNEL="linux" LCD_DEVICES="bayrad cfontz cfontz633 glk hd44780 lb216 lcdm001 mtxorb ncurses text" USERLAND="GNU" VIDEO_CARDS="vesa nv nvidia" Unset: CPPFLAGS, CTARGET, EMERGE_DEFAULT_OPTS, FFLAGS, INSTALL_MASK, LANG, LC_ALL, LINGUAS, PORTAGE_COMPRESS, PORTAGE_COMPRESS_FLAGS, PORTAGE_RSYNC_EXTRA_OPTS, PORTDIR_OVERLAY
I thought /dev/js* is for accessing joysticks from userspace.
/dev/js* is the classical name, but that doesnt cover the myriad of input devices out there (touchscreen much?). so /dev/input/event* seems to be the framework everything is coalescing on.
(In reply to comment #2) > /dev/js* is the classical name, but that doesnt cover the myriad of input > devices out there (touchscreen much?). so /dev/input/event* seems to be the > framework everything is coalescing on. > Right, but that provides a different API/ABI then the /dev/js* devices. Most apps which use joysticks use /dev/js*. Allowing these devices to be easily readable by non-privileged users provides a serious security concern (read: key loggers by regular users).
That security concern is mostly related to devices which would be accessed through the X server anyway (keyboard, mouse and maybe tablets). I do not see any security risks in making joysticks (and other such gaming devices) world-accessible. My knowledge of the capabilities of udev is quite limited, but would it not be possible to set the access rights to event files depending on the type of device that they represent?
no one was proposing we make all event devices directly accessible to the user. i was pointing out that using some event devices directly is not a bug.
So for this to get any further someone has to provide code, I only have mouse/keyboard and lirc (not yet using input layer).
Is this bug still accurate with current stable udev 197-r3? I guess so, but please verify.
I can confirm that permissions are still too strict with current udev-197-r4. They are rwxr----- root:root. But /dev/input/js0 is rwxr--r-- with the same ownership, which is fine.
(In reply to comment #8) > I can confirm that permissions are still too strict with current > udev-197-r4. They are rwxr----- root:root. But /dev/input/js0 is rwxr--r-- > with the same ownership, which is fine. Would it be somewhat crazy to have group & other have read permissions for eg. keyboard and mouse, allowing things like keyloggers? 700 sounds right, seems like the software assuming 744 has the bug here
or have dev-games/ois install as suid root to have such access if you think it's safe
You are not aware of the real issue here: For keyboard and pointer devices I would agree. These should belong either to root or the user owning the current terminal. But there is a host of other devices that need to be user-accessible. Joysticks and game controllers are good examples for that. Input of sensitive data is not usually performed with these devices and the only way to use them is through device files like /dev/input/event* or - sometimes, but not always - /dev/input/js*. OIS and Steam are two legitimate examples for software that wants to access /dev/input/event*. In the case of Steam, the inability to access these devices breaks Big Picture, the controller-friendly Steam UI, in a significant way. In the case of OIS, this breaks any game using it for joystick input. Make /dev/input/event* user-readable for any type of device that could be considered a gaming device. This requires some sort classification of the devices in the hardware database. Alternatively, change ownership to root:games and set the device files to 740. In either case, assuming 700 indiscriminately for all /dev/input/event* files is broken.
Re: Comment 10: I do not see how setting a shared library suid would help.
(In reply to comment #11) no input device should be world readable -- end of story you might be able to argue game group ownership of just joysticks, but even that is a bit of a hard sell i thought hal & friends used to handle this via like plugdev, but i don't know what the new hotness is there
I never spoke of input devices becoming world-readable in Comment 11. I chose the word user-accessible specifically to allow that only a single current user gets this kind of access. This would be a valid solution. Does this mean that ConsoleKit needs to be involved in this? Or is there another mechanism to track the currently active session?
Create group "input" and then: These to /lib/udev/rules.d/40-gentoo.rules: SUBSYSTEM=="input", KERNEL=="mouse*|mice|event*", MODE="0640", GROUP="input" SUBSYSTEM=="input", KERNEL=="js[0-9]*", MODE="0640", GROUP="input" To override these from /lib/udev/rules.d/50-udev-default.rules: SUBSYSTEM=="input", KERNEL=="mouse*|mice|event*", MODE="0640" SUBSYSTEM=="input", KERNEL=="js[0-9]*", MODE="0644" Then it should look like, for example: crw-r----- 1 root input 13, 63 Jan 28 00:53 /dev/input/mice crw-r----- 1 root input 13, 32 Jan 28 00:53 /dev/input/mouse0 crw-r----- 1 root input 13, 32 Jan 28 00:53 /dev/input/event0 Then admin can add the user to input group, or add input group to games group, depending on how much he trusts the users Does that make any sense?
(In reply to comment #13) > i thought hal & friends used to handle this via like plugdev, but i don't > know what the new hotness is there I can't think of any freedesktop package that would currently handle this; udisks is for disks and upower for power management, nothing generic for joysticks AFAIK "plugdev" group was also invention of HAL and is not something you can rely on, packages still needing it need to create the group themselfs...
(In reply to comment #16) isn't this the whole point of consolekit ? when you log into the "console" of the system, you should get automatic ownership of the "local" input devices.
(In reply to comment #17) > (In reply to comment #16) > > isn't this the whole point of consolekit ? when you log into the "console" > of the system, you should get automatic ownership of the "local" input > devices. right, sorry, sys-auth/consolekit[acl] would install udev-acl helper and /lib/udev/rules.d/70-udev-acl.rules and it already has this line: SUBSYSTEM=="input", ENV{ID_INPUT_JOYSTICK}=="?*", TAG+="udev-acl" which would set it ACL like crw-rw----+ but that only works for input devices that udev recognizes are joysticks and this bug seems to be about the ones that are joysticks but are not identified as such there is no rule in 70-udev-acl.rules that would do something for generic input devices
(In reply to comment #18) any reason for keeping the joystick limitation ? afaik, consolekit is limited to one console, so giving the user at said console write access to all event devices doesn't sound unreasonable.
Upstream commit, commit went in post-214, so it's currently only available in =sys-fs/udev-9999: http://cgit.freedesktop.org/systemd/systemd/commit/rules/50-udev-default.rules?id=3dff3e00e044e2d53c76fa842b9a4759d4a50e69 I believe we can close this bug finally.
21 Jun 2014; Samuli Suominen <ssuominen@gentoo.org> udev-9999.ebuild: Create group "input" wrt bugs #246847 and #514174 It will be available to ~arch with next release, udev-215 (or if I'm doing other fixes that need revision bumped 214, I'll include the patch too) Bug 514174 will follow it's inclusion to baselayout And I'm not comfortable adding ACLs for all input devices from ConsoleKit rules, it should be specific to what it recognizes as joysticks, otherwise it's security hazard (ie. local user can escalate privileges)
