* Re: udev permissions for USB
From: Xiaofan Chen @ 2010-10-25 3:28 UTC (permalink / raw)
To: linux-hotplug
In-Reply-To: <Pine.LNX.4.44L0.1010201004360.1626-100000@iolanthe.rowland.org>
On Fri, Oct 22, 2010 at 10:10 PM, Kay Sievers <kay.sievers@vrfy.org> wrote:
> On Wed, Oct 20, 2010 at 16:07, Alan Stern <stern@rowland.harvard.edu> wrote:
>> On Wed, 20 Oct 2010, Xiaofan Chen wrote:
>>> >From udev 163 release's 50-udev-default.rules.
>>> # libusb device nodes
>>> SUBSYSTEM="usb", ENV{DEVTYPE}="usb_device", MODE="0664"
>>>
>>> I wonder if this is better changed to using the "usb" or "plugdev"
>>> group and "0660". Then it is quite easy to ask the user to
>>> add them to the "usb" or "plugdev" group in order to use libusb
>>> based application as non-root user.
>
> Users are not put into any groups for device access these days.
>
> Certain classes of USB devices like printers, fingerprint readers,
> scanners, webcams, ... get ACLs assigned for locally logged-in users
> only.
>
> Group permissions on devices can be used from remote-logins which
> needs to be prevented for security reasons, like you don't want
> anybody logged-in over ssh to enable your webcam, or listen to your
> sound card.
>
I wonder if the default udev rule for libusb device (Mode 0664) follow your
reasoning. I do not think group based rule (Mode 0660 and using "plugdev"
group) is any worse than the default libusb udev rule for remote logged-in
users.
And there are plenty of group based rules in 50-udev-default.rules,
like sound, video and firewire device.
Eg: all the lines above the default libusb rules.
# sound
SUBSYSTEM="sound", GROUP="audio"
KERNEL="mixer0", SYMLINK+="mixer"
# DVB (video)
SUBSYSTEM="dvb", GROUP="video"
# FireWire (firewire-core driver: IIDC devices, AV/C devices)
SUBSYSTEM="firewire", ATTR{units}="*0x00a02d:0x00010*", GROUP="video"
SUBSYSTEM="firewire", ATTR{units}="*0x00b09d:0x00010*", GROUP="video"
SUBSYSTEM="firewire", ATTR{units}="*0x00a02d:0x010001*", GROUP="video"
SUBSYSTEM="firewire", ATTR{units}="*0x00a02d:0x014001*", GROUP="video"
# libusb device nodes
SUBSYSTEM="usb", ENV{DEVTYPE}="usb_device", MODE="0664"
Am I missing something obvious here?
--
Xiaofan
^ permalink raw reply
* Re: udev permissions for USB
From: Kay Sievers @ 2010-10-25 9:49 UTC (permalink / raw)
To: linux-hotplug
In-Reply-To: <Pine.LNX.4.44L0.1010201004360.1626-100000@iolanthe.rowland.org>
On Mon, Oct 25, 2010 at 05:28, Xiaofan Chen <xiaofanc@gmail.com> wrote:
> On Fri, Oct 22, 2010 at 10:10 PM, Kay Sievers <kay.sievers@vrfy.org> wrote:
>> On Wed, Oct 20, 2010 at 16:07, Alan Stern <stern@rowland.harvard.edu> wrote:
>>> On Wed, 20 Oct 2010, Xiaofan Chen wrote:
>>>> >From udev 163 release's 50-udev-default.rules.
>>>> # libusb device nodes
>>>> SUBSYSTEM="usb", ENV{DEVTYPE}="usb_device", MODE="0664"
>>>>
>>>> I wonder if this is better changed to using the "usb" or "plugdev"
>>>> group and "0660". Then it is quite easy to ask the user to
>>>> add them to the "usb" or "plugdev" group in order to use libusb
>>>> based application as non-root user.
>>
>> Users are not put into any groups for device access these days.
>>
>> Certain classes of USB devices like printers, fingerprint readers,
>> scanners, webcams, ... get ACLs assigned for locally logged-in users
>> only.
>>
>> Group permissions on devices can be used from remote-logins which
>> needs to be prevented for security reasons, like you don't want
>> anybody logged-in over ssh to enable your webcam, or listen to your
>> sound card.
>>
>
> I wonder if the default udev rule for libusb device (Mode 0664) follow your
> reasoning. I do not think group based rule (Mode 0660 and using "plugdev"
> group) is any worse than the default libusb udev rule for remote logged-in
> users.
>
> And there are plenty of group based rules in 50-udev-default.rules,
> like sound, video and firewire device.
>
> Eg: all the lines above the default libusb rules.
>
> # sound
> SUBSYSTEM="sound", GROUP="audio"
> KERNEL="mixer0", SYMLINK+="mixer"
>
> # DVB (video)
> SUBSYSTEM="dvb", GROUP="video"
>
> # FireWire (firewire-core driver: IIDC devices, AV/C devices)
> SUBSYSTEM="firewire", ATTR{units}="*0x00a02d:0x00010*", GROUP="video"
> SUBSYSTEM="firewire", ATTR{units}="*0x00b09d:0x00010*", GROUP="video"
> SUBSYSTEM="firewire", ATTR{units}="*0x00a02d:0x010001*", GROUP="video"
> SUBSYSTEM="firewire", ATTR{units}="*0x00a02d:0x014001*", GROUP="video"
>
> # libusb device nodes
> SUBSYSTEM="usb", ENV{DEVTYPE}="usb_device", MODE="0664"
>
> Am I missing something obvious here?
These are groups for system daemons like video grabbers and such, and
not groups to ever put individual users in.
The commonly used groups are device-class based matches only. The
udev-managed user ACLs are also class-based only, and not bus based.
They are no unpredictable match like 'all pci devices'. For example,
we must never grant access to a USB device which contains a
usb-storage blockdevice.
You can just add such a udev rule to systems you administrate, if
that's the behavior you expect and can be sure its not a security
issue. The default udev installation does not
suggest/recommend/support anything like this.
Thanks,
Kay
^ permalink raw reply
* Re: [RFD] Device Renaming Mechanism
From: Nao Nishijima @ 2010-10-25 10:55 UTC (permalink / raw)
To: Kay Sievers, greg
Cc: James.Bottomley, rwheeler, linux-kernel, linux-hotplug,
masami.hiramatsu.pt, Matt_Domsch
In-Reply-To: <AANLkTi=HzjWZbz7J92h9LCQijG8Zsv1YptFzN7d_G7eG@mail.gmail.com>
Hello,
(2010/10/18 21:33), Kay Sievers wrote:
>
> In short: it's a complete nightmare from the view of reliability, and
> I strongly suggest not even to think about to try that model on any
> other subsystem.
I see. I understood that network interface and block device are different.
> Device-mapper could maybe make the dm UUID mandatory, and use it as
> the device name. It will break a bunch of tools, which match on device
> names, but I guess it *could* be made working (if it does not involve
> any later renaming).
Indeed, device-mapper can provide a fixed name. However, still there is
mismatch between the dm device name and the troubling device name in kernel
log. That is the reason why I'm still sticking around the device renaming method.
In addition, using of device-mapper is worry about the performance and
management cost.
I think the method of using the intermediate device is the simplest solution.
Furthermore that method is compatible with old applications which are hard to
modify.
> I wouldn't even try. Besides the mentioned device mapper
> mandatory/non-changeable UUID=device-name approach which could work,
> I don't think that renaming of sd devices can be made working, without
> rewriting half of all existing userspace. :)
Even though, if it is only way to solve log-mismatch problem, I'd rather try to
rewrite a half of those tools. :-)
>
> Kay
>
>
Thank you for your advice.
Best Regards,
--
Nao NISHIJIMA
2nd Dept. Linux Technology Center
Hitachi, Ltd., Systems Development Laboratory
Email： nao.nishijima.xt@hitachi.com
^ permalink raw reply
* Re: udev permissions for USB
From: Xiaofan Chen @ 2010-10-26 3:22 UTC (permalink / raw)
To: linux-hotplug
In-Reply-To: <Pine.LNX.4.44L0.1010201004360.1626-100000@iolanthe.rowland.org>
On Mon, Oct 25, 2010 at 5:49 PM, Kay Sievers <kay.sievers@vrfy.org> wrote:
>> I wonder if the default udev rule for libusb device (Mode 0664) follow your
>> reasoning. I do not think group based rule (Mode 0660 and using "plugdev"
>> group) is any worse than the default libusb udev rule for remote logged-in
>> users.
>>
>> And there are plenty of group based rules in 50-udev-default.rules,
>> like sound, video and firewire device.
>>
>> Eg: all the lines above the default libusb rules.
>>
>> # sound
>> SUBSYSTEM="sound", GROUP="audio"
>> KERNEL="mixer0", SYMLINK+="mixer"
>>
>> # DVB (video)
>> SUBSYSTEM="dvb", GROUP="video"
>>
>> # libusb device nodes
>> SUBSYSTEM="usb", ENV{DEVTYPE}="usb_device", MODE="0664"
>>
>> Am I missing something obvious here?
>
> These are groups for system daemons like video grabbers and such, and
> not groups to ever put individual users in.
Thanks for the explanation, now it is clear to me.
> The commonly used groups are device-class based matches only. The
> udev-managed user ACLs are also class-based only, and not bus based.
> They are no unpredictable match like 'all pci devices'. For example,
> we must never grant access to a USB device which contains a
> usb-storage blockdevice.
>
> You can just add such a udev rule to systems you administrate, if
> that's the behavior you expect and can be sure its not a security
> issue. The default udev installation does not
> suggest/recommend/support anything like this.
>
The thread is from the following libusb mailing list thread, including
some OT rant about Linux.
http://libusb.6.n5.nabble.com/LibUSB-Claim-doesnt-work-td3217437.html
>> # libusb device nodes
>> SUBSYSTEM="usb", ENV{DEVTYPE}="usb_device", MODE="0664"
Changing the mode to "0666" is a "lazy" solution for system with only
one user (typical home desktop). But this is not a good solution for
other setup. That is why I think a group based solution is probably better.
Do you see any other possible solutions from udev (other than asking users to
create a new udev rule) so that libusb based applications can be made
to work right out of the box under Linux?
The permission problem seems to be forever present in libusb mailing list.
--
Xiaofan
^ permalink raw reply
* load firmware for in-kernel driver
From: Hr. Philip Rueegsegger @ 2010-10-26 22:19 UTC (permalink / raw)
To: linux-hotplug
Hi list,
I hope I have chosen the right mailing list for my problem.
I want to use a monolithic kernel (loadable module support disabled) for
security reasons. The in-kernel-driver for the network card (bnx2) needs
firmware to be loaded. Of course, when the kernel boots there is no filesystem
available from where the firmware can be loaded nor a firmware loader agent.
Thus I created a initrd containing the needed firmware in /lib/firmware and a
firmware loader agent script in /sbin/hotplug like this:
######################
#!/bin/sh -e
#
# firmware loader agent
#
if [ ! -e /sys/$DEVPATH/loading ]; then
mesg "/sys/$DEVPATH/ does not exist"
exit 1
fi
if [ -e "/lib/firmware/$FIRMWARE" ] ; then
echo 1 > /sys/$DEVPATH/loading
cat "/lib/firmware/$FIRMWARE" > /sys/$DEVPATH/data
echo 0 > /sys/$DEVPATH/loading
exit 0
done
# the firmware was not found
echo -1 > /sys/$DEVPATH/loading
mesg "Cannot find the $FIRMWARE firmware"
exit 1
######################
There is also a script /init mounting /proc and /sys.
The problem is, the kernel starts BEFORE the script /init of the ram disk is
executed. Thus I still have the problem of missing firmware support for the
in-kernel-driver.
Here are some additional infos:
Kernel version: 2.6.26 (Kernel source from Debian)
Distribution: Debian Lenny
The following firmware -and initrd related kernel features are enabled:
CONFIG_FW_LOADER=y
CONFIG_BLK_DEV_INITRD=y
Thanks in advance for any help or hint.
Cheers,
Phil
^ permalink raw reply
* Re: load firmware for in-kernel driver
From: Andrey Borzenkov @ 2010-10-27 12:36 UTC (permalink / raw)
To: linux-hotplug
In-Reply-To: <201010262219.o9QMJD0u004860@robo.generali.ch>
On Wed, Oct 27, 2010 at 2:19 AM, Hr. Philip Rueegsegger <rue@generali.ch> wrote:
> Hi list,
>
> I hope I have chosen the right mailing list for my problem.
>
> I want to use a monolithic kernel (loadable module support disabled) for
> security reasons. The in-kernel-driver for the network card (bnx2) needs
> firmware to be loaded. Of course, when the kernel boots there is no filesystem
> available from where the firmware can be loaded nor a firmware loader agent.
You can also compile firmware in kernel in which case request from
driver will be transparently served by compiled-in firmware.
> Kernel version: 2.6.26 (Kernel source from Debian)
Not sure when compiled-in firmware support was introduced first. Check
for CONFIG_FIRMWARE_IN_KERNEL.
^ permalink raw reply
* Re: load firmware for in-kernel driver
From: Hr. Philip Rueegsegger @ 2010-10-27 14:01 UTC (permalink / raw)
To: linux-hotplug
In-Reply-To: <201010262219.o9QMJD0u004860@robo.generali.ch>
>> I want to use a monolithic kernel (loadable module support disabled) for
>> security reasons. The in-kernel-driver for the network card (bnx2) needs
>> firmware to be loaded. Of course, when the kernel boots there is no
filesystem
>> available from where the firmware can be loaded nor a firmware loader agent.
>
>You can also compile firmware in kernel in which case request from
>driver will be transparently served by compiled-in firmware.
>Not sure when compiled-in firmware support was introduced first. Check
>for CONFIG_FIRMWARE_IN_KERNEL.
Unfortunately, for the kernel I'm using (2.6.26 from Debian Lenny), this is not
the case.
Is there no other possibility to accomplish this? For example, kind of postpone
loading of the driver?
^ permalink raw reply
* Re: load firmware for in-kernel driver
From: Kay Sievers @ 2010-10-27 14:10 UTC (permalink / raw)
To: linux-hotplug
In-Reply-To: <201010262219.o9QMJD0u004860@robo.generali.ch>
On Wed, Oct 27, 2010 at 16:01, Hr. Philip Rueegsegger <rue@generali.ch> wrote:
>>> I want to use a monolithic kernel (loadable module support disabled) for
>>> security reasons. The in-kernel-driver for the network card (bnx2) needs
>>> firmware to be loaded. Of course, when the kernel boots there is no
> filesystem
>>> available from where the firmware can be loaded nor a firmware loader agent.
>>
>
>>You can also compile firmware in kernel in which case request from
>>driver will be transparently served by compiled-in firmware.
>
>>Not sure when compiled-in firmware support was introduced first. Check
>>for CONFIG_FIRMWARE_IN_KERNEL.
>
> Unfortunately, for the kernel I'm using (2.6.26 from Debian Lenny), this is not
> the case.
>
> Is there no other possibility to accomplish this? For example, kind of postpone
> loading of the driver?
Yeah, you should use a recent kernel. :)
You can try to unbind/bind the driver from/to the device with
/sys/bus/pci/drivers/*/*bind. For some drivers it works that way.
Anyway, it's probably easier to leave it as a module. There are
thousand ways to get code into the running kernel with the right
permissions, disabling the module loader does not really add security.
Kay
^ permalink raw reply
* Re: load firmware for in-kernel driver
From: Hr. Philip Rueegsegger @ 2010-10-27 16:23 UTC (permalink / raw)
To: linux-hotplug
In-Reply-To: <201010262219.o9QMJD0u004860@robo.generali.ch>
>>>> I want to use a monolithic kernel (loadable module support disabled) for
>>>> security reasons. The in-kernel-driver for the network card (bnx2) needs
>>>> firmware to be loaded. Of course, when the kernel boots there is no
>>>> filesystem available from where the firmware can be loaded nor a firmware
>>>> loader agent.
>>>You can also compile firmware in kernel in which case request from
>>>driver will be transparently served by compiled-in firmware.
>>>
>>>Not sure when compiled-in firmware support was introduced first. Check
>>>for CONFIG_FIRMWARE_IN_KERNEL.
>> Unfortunately, for the kernel I'm using (2.6.26 from Debian Lenny), this is
>> not the case.
>>
>> Is there no other possibility to accomplish this? For example, kind of
>> postpone loading of the driver?
>Yeah, you should use a recent kernel. :)
>
>You can try to unbind/bind the driver from/to the device with
>/sys/bus/pci/drivers/*/*bind. For some drivers it works that way.
>
>Anyway, it's probably easier to leave it as a module. There are
>thousand ways to get code into the running kernel with the right
>permissions, disabling the module loader does not really add security.
Ah really? Even if /dev/kmem is disabled in the kernel? So, you mean it's not
worth the pain of having a monolithic kernel concerning security?
But still, besides this unbind/bind stuff or more recent kernel, is there really
no other solution to have a in-kernel-driver needing firmware? You know, I'd
like to stick with the kernel source provided by Debian just because of security
updates.
Thanks and Cheers,
Phil
^ permalink raw reply
* Re: load firmware for in-kernel driver
From: Karl O. Pinc @ 2010-10-27 17:02 UTC (permalink / raw)
To: linux-hotplug
In-Reply-To: <201010262219.o9QMJD0u004860@robo.generali.ch>
On 10/27/2010 11:23:57 AM, Hr. Philip Rueegsegger wrote:
> You
> know, I'd
> like to stick with the kernel source provided by Debian just because
> of security
> updates.
Use the newer kernel from backports.debian.org.
Karl <kop@meme.com>
Free Software: "You don't pay back, you pay forward."
-- Robert A. Heinlein
^ permalink raw reply
* Re: load firmware for in-kernel driver
From: Hr. Philip Rueegsegger @ 2010-10-27 17:48 UTC (permalink / raw)
To: linux-hotplug
In-Reply-To: <201010262219.o9QMJD0u004860@robo.generali.ch>
>On 10/27/2010 11:23:57 AM, Hr. Philip Rueegsegger wrote:
>> You
>> know, I'd
>> like to stick with the kernel source provided by Debian just because
>> of security
>> updates.
>
>Use the newer kernel from backports.debian.org.
What about security updates? Are they delivered equally regularely as from the
stable tree? After a quick look on http://backports.debian.org I couldn't see an
answer to my question. Thanks.
Cheers,
Phil
^ permalink raw reply
* Re: load firmware for in-kernel driver
From: Karl O. Pinc @ 2010-10-27 19:55 UTC (permalink / raw)
To: linux-hotplug
In-Reply-To: <201010262219.o9QMJD0u004860@robo.generali.ch>
On 10/27/2010 12:48:35 PM, Hr. Philip Rueegsegger wrote:
> >On 10/27/2010 11:23:57 AM, Hr. Philip Rueegsegger wrote:
> >> You
> >> know, I'd
> >> like to stick with the kernel source provided by Debian just
> because
> >> of security
> >> updates.
> >
> >Use the newer kernel from backports.debian.org.
>
> What about security updates? Are they delivered equally regularely as
> from the
> stable tree? After a quick look on http://backports.debian.org I
> couldn't see an
> answer to my question. Thanks.
Good question. I'd like to be sure of the answer myself.
Traditionally not, but backports is recently officially part of
Debian so things may have changed. The kernel also tends
to be more rigorously maintained and may be a
special case. The backports.debian.org FAQ says
security is best-effort but depends on the maintainer.
You might try asking security@debian.org or possibly
debian-kernel@lists.debian.org. The latter seems
to be listed as one of the package maintainers
so might be the right choice.
(The security team
faq says nothing about backports and now that it's
official maybe it should. The question in the
backports faq is weirdly grey-ed out and italicized;
that confuses me slightly.)
Karl <kop@meme.com>
Free Software: "You don't pay back, you pay forward."
-- Robert A. Heinlein
^ permalink raw reply
* Re: [Libusb-devel] udev permissions for USB
From: Peter Stuge @ 2010-10-27 21:11 UTC (permalink / raw)
To: linux-hotplug
Kay Sievers wrote:
> >> Certain classes of USB devices like printers, fingerprint readers,
> >> scanners, webcams, ... get ACLs assigned for locally logged-in users
> >> only.
Which is good, but I think things could be even better.
> The commonly used groups are device-class based matches only. The
> udev-managed user ACLs are also class-based only, and not bus based.
> They are no unpredictable match like 'all pci devices'. For example,
> we must never grant access to a USB device which contains a
> usb-storage blockdevice.
Of course not. I don't think that was the intent of the request.
I do see value in special treatment for "usbfs-capable" interfaces;
ie. those that have either usbfs or no driver at all bound.
> You can just add such a udev rule to systems you administrate, if
> that's the behavior you expect and can be sure its not a security
> issue. The default udev installation does not
> suggest/recommend/support anything like this.
I think it could make sense for it to do so, not for all USB devices,
but for those that have no driver.
I'm not sure if it can actually be done reliably though. Maybe it's
enough to react on when an interface appears and/or loses it's
driver.
//Peter
^ permalink raw reply
* Re: [Libusb-devel] udev permissions for USB
From: Kay Sievers @ 2010-10-28 0:52 UTC (permalink / raw)
To: linux-hotplug
In-Reply-To: <20101027211111.13771.qmail@stuge.se>
On Wed, Oct 27, 2010 at 23:11, Peter Stuge <peter@stuge.se> wrote:
> Of course not. I don't think that was the intent of the request.
>
> I do see value in special treatment for "usbfs-capable" interfaces;
> ie. those that have either usbfs or no driver at all bound.
All devices are usbfs capable, and usbfs can unbind any current driver.
We just don't want to encourage the use of any groups like this. With
the same argument we don't want other bus-specific groups like 'pci'
or 'scsi' group for device access permissions behind that bus.
People can do these things very easily in their custom setup, be it
for all usb devices, or with matches on vendor/product/class/...
That's all fine, but it should not be in the default setup.
Kay
^ permalink raw reply
* Re: load firmware for in-kernel driver
From: Greg KH @ 2010-10-28 1:19 UTC (permalink / raw)
To: linux-hotplug
In-Reply-To: <201010262219.o9QMJD0u004860@robo.generali.ch>
On Wed, Oct 27, 2010 at 07:48:35PM +0200, Hr. Philip Rueegsegger wrote:
> >On 10/27/2010 11:23:57 AM, Hr. Philip Rueegsegger wrote:
> >> You
> >> know, I'd
> >> like to stick with the kernel source provided by Debian just because
> >> of security
> >> updates.
> >
> >Use the newer kernel from backports.debian.org.
>
> What about security updates? Are they delivered equally regularely as from the
> stable tree? After a quick look on http://backports.debian.org I couldn't see an
> answer to my question. Thanks.
Why would you ask this on the linux-hotplug list and not the debian
lists?
If you are sticking with an old, obsolete kernel version like you want
to, you really are on your own, OR you need to get support from your
distro, not the upstream community.
good luck,
greg k-h
^ permalink raw reply
* how to generate udv trigger for a specific device ?
From: J. Bakshi @ 2010-10-28 4:59 UTC (permalink / raw)
To: linux-hotplug
Hello list,
I'm a newbie in udev rules and writing some very specific udev rules for my usb mouse. As per sysfs the mouse is detected as /sys/class/input/input11 and [ udevadm monitor /sys/class/input/input11 ] proves the detection. Now to test my udev rules which execute some action based on add / remove of the mouse, I have to physically add / remove the mouse. And for each and every change in my ruleset I have to do the same. Is there any way to generate the event by udevadm, so that my rules are fired based on the generated event ? I have tried by
````````````
udevadm trigger --verbose --sysname-match=/sys/class/input/input11 actiond
``````````````
But no luck. Could anyone please help me to generate the required event with udevadm please ?
Also interested to know, how to monitor the rules in action when the proper event is generated.
With regards
J. Bakshi
^ permalink raw reply
* how to generate udv trigger for a specific device ?
From: J. Bakshi @ 2010-10-28 4:59 UTC (permalink / raw)
To: linux-hotplug
In-Reply-To: <201010280447.o9S4lDZG001183@dcnode-01.unlimitedmail.net>
Hello list,
I'm a newbie in udev rules and writing some very specific udev rules for my usb mouse. As per sysfs the mouse is detected as /sys/class/input/input11 and [ udevadm monitor /sys/class/input/input11 ] proves the detection. Now to test my udev rules which execute some action based on add / remove of the mouse, I have to physically add / remove the mouse. And for each and every change in my ruleset I have to do the same. Is there any way to generate the event by udevadm, so that my rules are fired based on the generated event ? I have tried by
````````````
udevadm trigger --verbose --sysname-match=/sys/class/input/input11 actiond
``````````````
But no luck. Could anyone please help me to generate the required event with udevadm please ?
Also interested to know, how to monitor the rules in action when the proper event is generated.
With regards
J. Bakshi
^ permalink raw reply
* how to generate udv trigger for a specific device ?
From: J. Bakshi @ 2010-10-28 4:59 UTC (permalink / raw)
To: linux-hotplug
In-Reply-To: <201010280447.o9S4lDZG001183@dcnode-01.unlimitedmail.net>
Hello list,
I'm a newbie in udev rules and writing some very specific udev rules for my usb mouse. As per sysfs the mouse is detected as /sys/class/input/input11 and [ udevadm monitor /sys/class/input/input11 ] proves the detection. Now to test my udev rules which execute some action based on add / remove of the mouse, I have to physically add / remove the mouse. And for each and every change in my ruleset I have to do the same. Is there any way to generate the event by udevadm, so that my rules are fired based on the generated event ? I have tried by
````````````
udevadm trigger --verbose --sysname-match=/sys/class/input/input11 actiond
``````````````
But no luck. Could anyone please help me to generate the required event with udevadm please ?
Also interested to know, how to monitor the rules in action when the proper event is generated.
With regards
J. Bakshi
^ permalink raw reply
* Re: how to generate udv trigger for a specific device ?
From: J. Bakshi @ 2010-10-29 11:31 UTC (permalink / raw)
To: linux-hotplug
In-Reply-To: <201010280447.o9S4lDZG001183@dcnode-01.unlimitedmail.net>
Any clue please ?
On Thu, 28 Oct 2010 10:17:21 +0530
"J. Bakshi" <j.bakshi@unlimitedmail.org> wrote:
> Hello list,
>
> I'm a newbie in udev rules and writing some very specific udev rules for my usb mouse. As per sysfs the mouse is detected as /sys/class/input/input11 and [ udevadm monitor /sys/class/input/input11 ] proves the detection. Now to test my udev rules which execute some action based on add / remove of the mouse, I have to physically add / remove the mouse. And for each and every change in my ruleset I have to do the same. Is there any way to generate the event by udevadm, so that my rules are fired based on the generated event ? I have tried by
>
> ````````````
> udevadm trigger --verbose --sysname-match=/sys/class/input/input11 actiond
> ``````````````
>
> But no luck. Could anyone please help me to generate the required event with udevadm please ?
> Also interested to know, how to monitor the rules in action when the proper event is generated.
>
> With regards
> J. Bakshi
--
_____________________________________________________________________________
"Programming today is a race between software engineers striving to build
bigger and better idiot-proof programs and the universe trying to produce
bigger and\better idiots. So far, the universe is winning."
::::::Richard Cook
_____________________________________________________________________________
***************************************************************************************
Disclaimer : The information contained in this Message is confidential and
intended only for the use of the individual or entity identified. If the
reader of this message is not the intended recipient, any dissemination,
distribution or copying of the information contained in this message is
strictly prohibited. If you received this message in error, please notify the
sender immediately
***************************************************************************************
^ permalink raw reply
* keyboard udev rules
From: MONDON Daniel @ 2010-10-29 14:35 UTC (permalink / raw)
To: linux-hotplug
Hi
I think writing an udev rule is the better way of having a solution to
my problem.
I'am under Ubuntu 10.04 (live CD - kernel 2.6.32 - Xorg server 1.7.6).
My application is totally managed by touch screen.
I don't need any keyboard or mouse, and I don't want users to have
system or files access.
For that, I need to deactivate keyboard.
I know how I can do that in the xorg.conf file.
But I don't have it (don't want to generate xorg.conf).
And I have to go to the machine WITH keyboard activated in order to
maintain system, without reboot.
So, I want to write two udev rules. (because they can be run
dynamically)
One to activate keyboard (and mouse)
One to de activate keyboard.
And if keyboard is plugged at boot time, or with hot plug.
I don't know the keyboard identification.
I'm looking over web to find the kernel keyboard name ...
I'm thinking to a rule like that ... but ...
ACTION="add", NAME="%keyboard", OPTION+="ignore_device last_rule"
Can somebody help me, please?
I don't find any specific information to confirm my thinking.
What I suggest is the result of the compilation of what I found over
internet.
Thanks,
Daniel.
^ permalink raw reply
* Sysfs properties with libudev (for example capabilities/key)
From: Laszlo Papp @ 2010-10-30 21:17 UTC (permalink / raw)
To: linux-hotplug
Hi,
I would like to get the capabilities/key entry from sysfs for my
keyboard for example with libudev library.
From the documentation:
http://www.signal11.us/oss/udev/
'Any non-directory file or link in that directory can be queried with
udev_device_get_sysattr_value() to determine the properties of the
device.'
Hence in essence: the problem is that I can use
udev_device_get_sysattr_value(dev,"idVendor") way only for simple
files under the related sysfs entry, but I would to use in case a
'hello/world' file where 'hello' is the directory which contains the
'world' file. I hope I was clear, but feel free to contact me if you
need help with anything about the clarification. Thank you in advance!
Best Regards,
Laszlo Papp
^ permalink raw reply
* Sysfs properties with libudev (for example capabilities/key)
From: Laszlo Papp @ 2010-10-30 21:23 UTC (permalink / raw)
To: linux-hotplug
In-Reply-To: <AANLkTi=z2McbB95XxgZ5kFoojeLVOGWHfYQCtLFJfw3e@mail.gmail.com>
Hi,
I would like to get the capabilities/key entry from sysfs for my
keyboard for example with libudev library.
From the documentation:
http://www.signal11.us/oss/udev/
'Any non-directory file or link in that directory can be queried with
udev_device_get_sysattr_value() to determine the properties of the
device.'
Hence in essence: the problem is that I can use
udev_device_get_sysattr_value(dev,"idVendor") way only for simple
files under the related sysfs entry, but I would to use in case a
'hello/world' file where 'hello' is the directory which contains the
'world' file. I hope I was clear, but feel free to contact me if you
need help with anything about the clarification. Thank you in advance!
Best Regards,
Laszlo Papp
^ permalink raw reply
* Re: Sysfs properties with libudev (for example capabilities/key)
From: Greg KH @ 2010-10-31 1:39 UTC (permalink / raw)
To: linux-hotplug
In-Reply-To: <AANLkTi=z2McbB95XxgZ5kFoojeLVOGWHfYQCtLFJfw3e@mail.gmail.com>
On Sat, Oct 30, 2010 at 02:17:20PM -0700, Laszlo Papp wrote:
> Hi,
>
> I would like to get the capabilities/key entry from sysfs for my
> keyboard for example with libudev library.
Have you tried it? It works here for me using libudev, do you have a
pointer to your code that does not work properly?
thanks,
greg k-h
^ permalink raw reply
* Re: Sysfs properties with libudev (for example capabilities/key)
From: Laszlo Papp @ 2010-10-31 14:04 UTC (permalink / raw)
To: linux-hotplug
In-Reply-To: <AANLkTi=z2McbB95XxgZ5kFoojeLVOGWHfYQCtLFJfw3e@mail.gmail.com>
Hi,
You can check the code out more in-depth in the following with the
produced output. This is the compilation command I used for testing:
gcc -Wall -o test -ggdb -ludev main.c.
I just would like to get the real input devices.. so VID/PID: (null)
(null) and related device node entries are undesired. In essence I get
more outputs that I would expect because I expect the real entries
where I can use sysattr later and so on. I have just checked
get_parent method, but that did not help me too much.
Thank you in advance!
Best Regards,
Laszlo Papp
[code]
#include <libudev.h>
#include <stdio.h>
int main()
{
struct udev *udev;
struct udev_enumerate *enumerate;
struct udev_list_entry *devices;
struct udev_list_entry *dev_list_entry;
struct udev_device *dev;
udev = udev_new();
if (!udev) {
printf("Cannot create udev\n");
return -1;
}
enumerate = udev_enumerate_new(udev);
udev_enumerate_add_match_subsystem(enumerate, "input");
udev_enumerate_scan_devices(enumerate);
devices = udev_enumerate_get_list_entry(enumerate);
udev_list_entry_foreach(dev_list_entry, devices) {
const char *path;
path = udev_list_entry_get_name(dev_list_entry);
dev = udev_device_new_from_syspath(udev, path);
printf("Device Node Path: %s, Name: %s\r\n", path,
udev_device_get_sysattr_value(dev, "name"));
printf("VID/PID: %s %s\r\n",
udev_device_get_sysattr_value(dev,"id/vendor"),
udev_device_get_sysattr_value(dev, "id/product"));
udev_device_unref(dev);
}
udev_enumerate_unref(enumerate);
udev_unref(udev);
return 0;
}
[/code]
Device Node Path: /sys/devices/LNXSYSTM:00/LNXPWRBN:00/input/input3,
Name: Power Button
VID/PID: 0000 0001
Device Node Path:
/sys/devices/LNXSYSTM:00/LNXPWRBN:00/input/input3/event3, Name: (null)
VID/PID: (null) (null)
Device Node Path:
/sys/devices/LNXSYSTM:00/LNXSYBUS:00/PNP0C0C:00/input/input2, Name:
Power Button
VID/PID: 0000 0001
Device Node Path:
/sys/devices/LNXSYSTM:00/LNXSYBUS:00/PNP0C0C:00/input/input2/event2,
Name: (null)
VID/PID: (null) (null)
Device Node Path:
/sys/devices/pci0000:00/0000:00:04.0/usb2/2-10/2-10:1.0/input/input5,
Name: Logitech USB Optical Mouse
VID/PID: 046d c00c
Device Node Path:
/sys/devices/pci0000:00/0000:00:04.0/usb2/2-10/2-10:1.0/input/input5/event5,
Name: (null)
VID/PID: (null) (null)
Device Node Path:
/sys/devices/pci0000:00/0000:00:04.0/usb2/2-10/2-10:1.0/input/input5/mouse1,
Name: (null)
VID/PID: (null) (null)
Device Node Path: /sys/devices/pci0000:00/0000:00:09.0/input/input6,
Name: HDA Digital PCBeep
VID/PID: 10ec 0662
Device Node Path:
/sys/devices/pci0000:00/0000:00:09.0/input/input6/event6, Name: (null)
VID/PID: (null) (null)
Device Node Path: /sys/devices/platform/i8042/serio0/input/input1,
Name: AT Translated Set 2 keyboard
VID/PID: 0001 0001
Device Node Path:
/sys/devices/platform/i8042/serio0/input/input1/event1, Name: (null)
VID/PID: (null) (null)
Device Node Path: /sys/devices/platform/pcspkr/input/input4, Name: PC Speaker
VID/PID: 001f 0001
Device Node Path: /sys/devices/platform/pcspkr/input/input4/event4, Name: (null)
VID/PID: (null) (null)
Device Node Path: /sys/devices/virtual/input/input0, Name: Macintosh
mouse button emulation
VID/PID: 0001 0001
Device Node Path: /sys/devices/virtual/input/input0/event0, Name: (null)
VID/PID: (null) (null)
Device Node Path: /sys/devices/virtual/input/input0/mouse0, Name: (null)
VID/PID: (null) (null)
Device Node Path: /sys/devices/virtual/input/mice, Name: (null)
VID/PID: (null) (null)
On Sat, Oct 30, 2010 at 6:39 PM, Greg KH <greg@kroah.com> wrote:
> On Sat, Oct 30, 2010 at 02:17:20PM -0700, Laszlo Papp wrote:
>> Hi,
>>
>> I would like to get the capabilities/key entry from sysfs for my
>> keyboard for example with libudev library.
>
> Have you tried it? It works here for me using libudev, do you have a
> pointer to your code that does not work properly?
>
> thanks,
>
> greg k-h
>
^ permalink raw reply
* Re: Sysfs properties with libudev (for example capabilities/key)
From: Greg KH @ 2010-10-31 14:23 UTC (permalink / raw)
To: linux-hotplug
In-Reply-To: <AANLkTi=z2McbB95XxgZ5kFoojeLVOGWHfYQCtLFJfw3e@mail.gmail.com>
On Sun, Oct 31, 2010 at 07:04:30AM -0700, Laszlo Papp wrote:
> Hi,
>
> You can check the code out more in-depth in the following with the
> produced output. This is the compilation command I used for testing:
> gcc -Wall -o test -ggdb -ludev main.c.
>
> I just would like to get the real input devices.. so VID/PID: (null)
> (null) and related device node entries are undesired.
But those are "real" input devices, why do you think otherwise?
If you don't want them, then filter them out by ignoring the event
types, but note that they are needed by your system to work properly
(i.e. x.org uses them.)
So your code is working as designed, I just don't think that you
realized there are all of these input devices present :)
thanks,
greg k-h
^ permalink raw reply
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox