linux-kernel - Re: [PATCH 2/2] uevent: handle duplicate uevent

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] [thread-next>] [day] [month] [year] [list]

Message-ID: <3ae72650808290048v1a5d7e51pc68270b2a8d6faa@mail.gmail.com>
Date:	Fri, 29 Aug 2008 09:48:02 +0200
From:	"Kay Sievers" <kay.sievers@...y.org>
To:	"Tejun Heo" <tj@...nel.org>
Cc:	"Greg KH" <greg@...ah.com>,
	"Linux Kernel Mailing List" <linux-kernel@...r.kernel.org>
Subject: Re: [PATCH 2/2] uevent: handle duplicate uevent_var keys properly

On Thu, Aug 28, 2008 at 19:00, Tejun Heo <tj@...nel.org> wrote:
> Greg KH wrote:
>> On Thu, Aug 28, 2008 at 06:31:02PM +0200, Tejun Heo wrote:
>>> add_uevent_var() appends the specified variable whether the new entry
>>> has duplicate key or not.  This patch makes add_uevent_var() to
>>> override the existing entry if an entry with the same key is added
>>> later.  This will be used by CUSE (character device in userland) to
>>> fake hotplug events.
>>
>> Hm, do you have any pointers to CUSE, that sounds interesting.
>
> I'm in the process of sending patches.  I'll cc you on the actual postings.
>
>> And how would this change interact with fake hotplug events?
>
> CUSE creates actual devices but those devices are all cuse class
> devices.  To play nicely with sysfs/hal, the ADD/REMOVE uevents should
> have about the same variables as the actual device including the
> SUBSYSTEM, so that's where the overriding comes in.  CUSE client tells
> CUSE that it needs to set such such envs for uevents and CUSE overrides
> uevents before sending it out so that sysfs/hal can be fooled.

Not sure if I understand that correctly. Remember, that there is a
symlink "subsystem" at each device, and udev, HAL, DeviceKit reads it.
If the uevent environment key "SUBSYSTEM" does not match the symlink
target, things will break horribly. So no device can be a member of
class "cuse" but carry a SUBSYSTEM value of a different class.

If that is how it works, I guess that must be solved differently, by
hooking into the subsystem code and create "virtual devices" at the
original class they fake, instead of their own "cuse" class. Possibly
by making cuse a "bus", and use the cuse device as a parent for the
"real" class device.

Thanks,
Kay
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/