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:	Fri, 7 Mar 2008 07:59:21 -0800
From:	Greg KH <greg@...ah.com>
To:	Pavel Emelyanov <xemul@...nvz.org>
Cc:	Andrew Morton <akpm@...ux-foundation.org>,
	linux-kernel@...r.kernel.org, menage@...gle.com,
	sukadev@...ibm.com, serue@...ibm.com
Subject: Re: [PATCH 5/9] Make use of permissions, returned by kobj_lookup

On Fri, Mar 07, 2008 at 12:52:40PM +0300, Pavel Emelyanov wrote:
> Andrew Morton wrote:
> > On Fri, 07 Mar 2008 12:22:01 +0300 Pavel Emelyanov <xemul@...nvz.org> wrote:
> > 
> >>> This doesn't include sufficient headers to be compileable.
> >>>
> >>> I'm sure there are lots of headers like this.  But we regularly need
> >>> to fix them.
> >>>
> >> Not sure, whether this is still relevant after Greg's comments, but that's
> >> the -fix patch for this one. (It will cause a conflict with the 9th patch.)
> > 
> > Well.  Where do we stand with this?  afaict the state of play is:
> > 
> > Greg: do it in udev
> > Pavel: but people want to run old distros in containers
> 
> Actually no.
> 
> Greg: Use LSM for this

Yes, that is my recommendation.

> Pavel: My approach just makes maps per-group, while LSM will
>        bring a new level of filtering/lookup on device open path

Huh?  You are still doing that same "filtering/lookup" by modifying the
maps code.  The result should be exactly the same.

Why do you not want to use the LSM interface?  That is exactly what it
is there for, don't go creating new hooks into the kernel for the exact
same functionality.

Opening a dev node is not on any "fast path" that you need to be
concerned about a few extra calls within the kernel.

And, I think in the end your patch would be much smaller and easier to
understand and review and maintain overall.

> > Realistically, when is the mainline kernel likely to have sufficient
> > container functionality which is sufficiently well-tested for people to
> > actually be able to do that?  And how much longer will it take for that
> > kernel.org functionality to propagate out into non-bleeding-edge distros?
> 
> The fact is that we have users of OpenVZ and even Virtuozzo, that still use 
> redhat-9 as in containers. So even if this is ready in 5 years, there will 
> always be someone who sets the outdated (by that time) fedora-core-8 and find
> out, that his udev refuses to work.

That's fine, use the LSM interface, no need to change userspace at all.

Although I think your requirement of using new kernels on very old
distros is going to cause you more problems than you realize in the
end...

thanks,

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/

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ