linux-kernel - Re: sysfs: tagged directories not merged completely yet

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: <20081007222726.GA9465@kroah.com>
Date:	Tue, 7 Oct 2008 15:27:26 -0700
From:	Greg KH <greg@...ah.com>
To:	"Eric W. Biederman" <ebiederm@...ssion.com>
Cc:	Al Viro <viro@...IV.linux.org.uk>,
	Benjamin Thery <benjamin.thery@...l.net>,
	linux-kernel@...r.kernel.org, "Serge E. Hallyn" <serue@...ibm.com>,
	Al Viro <viro@....linux.org.uk>,
	Linus Torvalds <torvalds@...ux-foundation.org>,
	Tejun Heo <tj@...nel.org>
Subject: Re: sysfs: tagged directories not merged completely yet

On Tue, Oct 07, 2008 at 01:27:17AM -0700, Eric W. Biederman wrote:
> Unless someone will give an example of how having multiple superblocks
> sharing inodes is a problem in practice for sysfs and call it good
> for 2.6.28.  Certainly it shouldn't be an issue if the network namespace
> code is compiled out.  And it should greatly improve testing of the
> network namespace to at least have access to sysfs.

But if the network namespace code is in?  THen we have problems, right?
And that's the whole point here.

The fact that you are trying to limit userspace view of in-kernel data
structures, based on that specific user, is, in my opinion, crazy.

Why not just keep all users from seeing sysfs, and then have a user
daemon doing something on top of FUSE if you really want to see this
kind of stuff.

The "leakage" just seems too hard to stop.

> Later Tejun or I or possibly someone else who cares can go back
> and simplify the sysfs locking to remove the need for multiple
> superblocks sharing inodes, and to address the other big nasties in
> the current sysfs implementation.  

I know how the whole "we'll go back later and fix it up" stuff works,
I've used that excuse too many times in the past myself.  Never happens
:)

> Greg I agree with Al that sysfs isn't perfect but we sure aren't going
> to fix it if you keep dropping or taking years to merge every patch
> from the people working on it, and then dropping those patches because
> someone frowns at them.

"years"?  Come on, these did take a while due to travel and other stuff.
These are core kernel changes, and need time to ensure that they work
properly, and get the proper review from people who understand this kind
of stuff.

And to call Al a generic "someone", is just rude and disrespectful.  I
trust his opinion in this area far more than I do yours, to be honest.

This whole series is dropped, if you want to resubmit them, feel free
to, _after_ adressing his issues.

bah,

greg k-h
--
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/