linux-kernel - Re: [PATCH 10/11] avoid kobject name conflict with different namespaces

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: <m1tzh8d2e9.fsf@frodo.ebiederm.org>
Date:	Thu, 08 May 2008 12:25:18 -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 :)
>
>> 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.  I thought that s390 also used it, but I don't see
> that usage in the tree anymore, perhaps they switched to something else.

Looking at this a little further kobject_rename is a complete noop
when sysfs support is not compiled in.  That is the kobject does not
get renamed, even if the higher level objects do.

This makes the wireless dependency on an error code from kobject_rename
completely bogus as the kobject layer is not prepared to give any kind of
reliable result, and it makes kobject_rename completely bogus if sysfs
support is not compiled in.

Further there is no locking to guarantee renames are atomic
or mutually exclusive at the kobject level.

With no locking and code that does nothing in the absence of sysfs
attempting to check renames for validity at the kobject level (when
renames don't happen at the kobject level) is totally bogus.

Since renames don't happen at the kobject level checking them for
sanity at the kobject level makes no sense.

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/