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]
Date:	Wed, 07 May 2008 13:54:27 -0700
From:	ebiederm@...ssion.com (Eric W. Biederman)
To:	Greg KH <gregkh@...e.de>
Cc:	Benjamin Thery <benjamin.thery@...l.net>,
	linux-kernel@...r.kernel.org, Tejun Heo <htejun@...il.com>,
	Al Viro <viro@....linux.org.uk>,
	Daniel Lezcano <dlezcano@...ibm.com>,
	"Serge E. Hallyn" <serue@...ibm.com>,
	Pavel Emelyanov <xemul@...nvz.org>, netdev@...r.kernel.org
Subject: Re: [PATCH 10/11] avoid kobject name conflict with different namespaces

Greg KH <gregkh@...e.de> writes:

> On Wed, May 07, 2008 at 11:49:19AM -0700, Eric W. Biederman wrote:
>> Unless there is another path I think placing an additional pointer in
>> kobj_type so we can find it through ktype is the simplest solution.
>> Although using the kset is also sane.
>
> Ick, ick, ick :)

Well yes we are dealing with a pile of seemingly unnecessary layers,
that are attempting to add uniformity where no uniformity existed.
That is an easy recipe for ick.

>> The easiest and most trivially correct thing to do would be to simply
>> remove the unnecessary check from kobject_rename.  We perform the
>> check at the upper levels in the network anyway.  And kobject_rename
>> is only used by the network stack.
>
> Wireless uses it also for some things, and it requires that it fail if a
> duplicate is found.

Looks like it, that use is brand new, and at first glance I thought
it was another instance of the device_rename case that kobject uses.
Apparently not.

It looks like getting the wireless devices into the network namespace
is going to be interesting.  Since this phy name is user controllable
and shows up in rtnetlink messages it definitely appears to belong in
the network namespace. 

Virtual/logical devices are such a pain.

....

Given that kobject_rename is growing users we definitely need to
fix it so a noop rename does not return -EINVAL.

i.e. if (temp_kobj && (temp_kobj != kobj)) return -EINVAL.
instead of just if (temp_kobj) return -EINVAL;

> I thought that s390 also used it, but I don't see
> that usage in the tree anymore, perhaps they switched to something else.

That is the device_move -> kobject_move case.  Very similar (and nice
if we can figure out how to combine them).

> good luck,

Thanks.  It looks like we are just about there.

Hopefully we can get this merged soon so there won't be many more sets
of shifting requirements to chase.

Eric
--
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/

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ