On Mon, 2022-11-21 at 12:05 +0100, Greg Kroah-Hartman wrote:

On Sun, Nov 20, 2022 at 10:14:26PM -0500, James Bottomley wrote:

quoted

On Sun, 2022-11-20 at 17:13 +0100, Greg Kroah-Hartman wrote:

quoted

On Sat, Nov 19, 2022 at 01:20:09AM -0500, Nayna wrote:

quoted

On 11/17/22 16:27, Greg Kroah-Hartman wrote:

quoted

On Mon, Nov 14, 2022 at 06:03:43PM -0500, Nayna wrote:

quoted

On 11/10/22 04:58, Greg Kroah-Hartman wrote:

[...]

quoted

quoted

quoted

quoted

quoted

I do not understand, sorry.  What does namespaces have to
do
with this?
sysfs can already handle namespaces just fine, why not
use
that?

Firmware objects are not namespaced. I mentioned it here as
an
example of the difference between firmware and kernel
objects.
It is also in response to the feedback from James Bottomley
in
RFC v2 [
https://lore.kernel.org/linuxppc-dev/41ca51e8db9907d9060cc38ad
b59a66dcae4c59b.camel@HansenPartnership.com/].

I do not understand, sorry.  Do you want to use a namespace
for
these or not?  The code does not seem to be using
namespaces. 
You can use sysfs with, or without, a namespace so I don't
understand the issue here.

With your code, there is no namespace.

You are correct. There's no namespace for these.

So again, I do not understand.  Do you want to use filesystem
namespaces, or do you not?

Since this seems to go back to my email quoted again, let me
repeat: the question isn't if this patch is namespaced; I think
you've agreed several times it isn't.  The question is if the
exposed properties would ever need to be namespaced.  This is a
subtle and complex question which isn't at all explored by the
above interchange.

quoted

How again can you not use sysfs or securityfs due to namespaces? 
What is missing?

I already explained in the email that sysfs contains APIs like
simple_pin_... which are completely inimical to namespacing.

Then how does the networking code handle the namespace stuff in
sysfs?
That seems to work today, or am I missing something?

have you actually tried?

jejb@lingrow:~> sudo unshare --net bash
lingrow:/home/jejb # ls /sys/class/net/
lo  tun0  tun10  wlan0
lingrow:/home/jejb # ip link show
1: lo: <LOOPBACK> mtu 65536 qdisc noop state DOWN mode DEFAULT group
default qlen 1000
    link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00

So, as you see, I've entered a network namespace and ip link shows me
the only interface I can see in that namespace (a down loopback) but
sysfs shows me every interface on the system outside the namespace.

This is pretty much the story of containers and sysfs: if you mount it
inside the container, it leaks information about the host
configuration.  Since I created a container with full root, I could
actually fiddle with the host network parameters on interfaces I
shouldn't be able to see within the container using sysfs ... which is
one reason we try to persuade people to use a user namespace instead of
full root.
 

If the namespace support needs to be fixed up in sysfs (or in
securityfs), then great, let's do that, and not write a whole new
filesystem just because that's not done.

As I said: a fix is proposed for securityfs.  I think everyone in
containers concluded long ago that sysfs is too big an Augean Stable.

Also this patch series also doesn't handle namespaces, so again, I am
totally confused as to why this is even being discussed...

Well, it's not my patch.  I came into this saying *if* there was ever a
reason to namespace these parameters then please don't use interfaces
inimical to namespacing.  My personal view is that this should all just
go in securityfs because that defers answering the question of whether
it would eventually be namespaced.

James