linux-kernel - Re: [RFC PATCH] input: Add disable sysfs entry for every input device

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [day] [month] [year] [list]

Date:   Mon, 19 Feb 2018 08:50:24 +1000
From:   Peter Hutterer <peter.hutterer@...-t.net>
To:     Pavel Machek <pavel@....cz>
Cc:     Pali Rohár <pali.rohar@...il.com>,
        Bastien Nocera <hadess@...ess.net>,
        Dmitry Torokhov <dmitry.torokhov@...il.com>,
        Ivaylo Dimitrov <ivo.g.dimitrov.75@...il.com>,
        Sebastian Reichel <sre@...nel.org>,
        Mauro Carvalho Chehab <mchehab@....samsung.com>,
        Chuck Ebbert <cebbert.lkml@...il.com>,
        Henrik Rydberg <rydberg@...omail.se>,
        linux-input@...r.kernel.org, linux-kernel@...r.kernel.org
Subject: Re: [RFC PATCH] input: Add disable sysfs entry for every input device

On Sat, Feb 17, 2018 at 10:19:14PM +0100, Pavel Machek wrote:
> Hi!
> 
> > > > > So, do you mean to implement this "disable" action as ioctl for
> > > > > particular /dev/input/event* device (instead of sysfs entry)?
> > > > 
> > > > Yes, so the device can be powered down without the device node being
> > > > closed and made unavailable. I don't know whether that's something
> > > > that's already possible for all cases, but there's already
> > > > opportunistic in a lot of drivers and subsystems.
> > > > 
> > > > This opens up a whole new wave of potential problems, but it's a more
> > > > generally useful mechanism, I would think.
> > > 
> > > Ok. How should API for this ioctl looks like? And do you have an idea
> > > for name of that ioctl?
> > > 
> > > Dmitry, what do you think about it? It is acceptable for you?
> > 
> > first: sysfs files are pretty terrible because writing to them requires root
> > and we don't have the benefit of logind. so for any sysfs toggle expect
> > a nicely integrated userspace solution to be less than optimal.
> 
> Well, you can chmod / chown sysfs files.

and that's what I meant by "less than optimal" :)
you're either chmodding, or suid, or any of the other solutions that aren't
really good in the long run.

> > besides: 99% of the above is figuring out the policy *when* to disable the
> > device. disabling it is trivial by just closing the evdev nodes and tbh I
> > don't think we (in userspace) should care about whether the device is
> > powered down or now, it should be the default assumption that it is powered
> > down when not in use.
> > 
> > for the cases where you must keep the device open but you don't want events, 
> > EVIOCSMASK is likely the best solution. improving the kernel so it powers
> > down the device when the mask excludes all events (and there are no other
> > listeners) could be an interesting task.
> 
> But yes, that sounds like an idea.
> 
> BTW in the meantime, someone added this to pmos wiki... this should
> solve some of my problems.
> 
> Best regards,
> 								Pavel
> 
> 
> 
> FILE=~/.screenoff
> if [ -f $FILE ]; then
>  xinput set-prop 8 "Device Enabled" 1
>  xinput set-prop 6 "Device Enabled" 1
>  xinput set-prop 9 "Device Enabled" 1
>  xset dpms force on
>  rm ~/.screenoff
> else
>  xinput set-prop 8 "Device Enabled" 0
>  xinput set-prop 6 "Device Enabled" 0
>  xinput set-prop 9 "Device Enabled" 0
>  xset dpms force off
>  touch ~/.screenoff
> fi

xinput can resolve device names, using device ids is likely to cause upset.
http://who-t.blogspot.com/2016/07/xinput-resolves-device-names-and.html

Cheers,
   Peter