Re: [PATCH 01/11] SYSCTL: export root and set handling routines

Stanislav Kinsbursky [off-list ref] writes:

11.01.2012 02:39, Eric W. Biederman пишет:

quoted

Stanislav Kinsbursky[off-list ref]  writes:

quoted

03.01.2012 07:49, Eric W. Biederman пишет:

quoted

Stanislav Kinsbursky[off-list ref]   writes:

quoted

19.12.2011 20:37, Eric W. Biederman пишет:

quoted

Stanislav Kinsbursky[off-list ref]    writes:

Doing that independently of the rest of the sysctls is pretty horrible
and confusing to users.   What I am planning might suit your needs and
if not we need to talk some more about how to get the vfs to do
something reasonable.

Ok, Eric. Would be glad to discuss your sysctls plans.
But actually you already know my needs: I would like to make sysctls work in the
way like sysfs does: i.e. content of files depends on mount maker -
not viewer.

What drives the desire to have sysctls depend on the mount maker?

Because we can (will, actually) have nested fs root's for containers. IOW,
container's root will be accessible from it's creator context. And I want to
tune container's fs from creators context.

Tuning the child context from the parent context is an entirely
reasonable thing to do.  To affect a namespace that is not yours
the requirement is simply that we don't use current to lookup the
sysctl.  So what I am proposing should work for your case.

Could you explain, what are you proposing?
I still don't know any details about it.

I am proposing treating /proc/sys like /proc/net is currently treated.
See below.

quoted

quoted

quoted

Especially what drives that desire not to have it have a /proc/<pid>/sys
directory that reflects the sysctls for a given process.

This is not so important for me, where to access sysctl's. But I'm worrying
about backward compatibility. IOW, I'm afraid of changing path
"/proc/sys/sunprc/*" to "/proc/<pid>/sys/sunrpc". This would break a lot of
user-space programs.

The part that keeps it all working is by adding a symlink from /proc/sys
to /proc/self/sys.  That technique has worked well for /proc/net, and I
don't expect there will be any problems with /proc/sys either.  It is
possible but is very rare for the introduction of a symlink in a path
to cause problems.

Probably I don't understand you, but as I see it now, symlink to "/proc/self/"
is unacceptable because of the following:
1) will be used current context (any) instead of desired one

(Using the current context is the desirable outcome for existing tools).

1) if CT has other pid namespace - then we just have broken link.

Assuming the process in question is not in the pid namespace available
to proc then yes you will indeed have a broken link.  But a broken
link is only a problem for new applications that are doing something strange.

I am proposing treating /proc/sys like /proc/net has already been
treated.  Aka move have the version of /proc/sys that relative to a
process be visible at: /proc/<pid>/sys, and with a compat symlink 
from /proc/sys -> /proc/self/sys.

Just like has already been done with /proc/net.

Semantically this should be easy to understand, and about as backwards
compatible as it gets.

Eric

11.01.2012 21:21, Eric W. Biederman пишет:

quoted

quoted

quoted

quoted

Especially what drives that desire not to have it have a /proc/<pid>/sys
directory that reflects the sysctls for a given process.

This is not so important for me, where to access sysctl's. But I'm worrying
about backward compatibility. IOW, I'm afraid of changing path
"/proc/sys/sunprc/*" to "/proc/<pid>/sys/sunrpc". This would break a lot of
user-space programs.

The part that keeps it all working is by adding a symlink from /proc/sys
to /proc/self/sys.  That technique has worked well for /proc/net, and I
don't expect there will be any problems with /proc/sys either.  It is
possible but is very rare for the introduction of a symlink in a path
to cause problems.

Probably I don't understand you, but as I see it now, symlink to "/proc/self/"
is unacceptable because of the following:
1) will be used current context (any) instead of desired one

(Using the current context is the desirable outcome for existing tools).

quoted

1) if CT has other pid namespace - then we just have broken link.

Assuming the process in question is not in the pid namespace available
to proc then yes you will indeed have a broken link.  But a broken
link is only a problem for new applications that are doing something strange.

I believe, that container is assuming to work in  it's own network and pid 
namespaces.
With your approach, if I'm not mistaken, container's /proc/net and /proc/sys 
tunables will be unaccessible from parent environment. Or I'm wrong here?

I am proposing treating /proc/sys like /proc/net has already been
treated.  Aka move have the version of /proc/sys that relative to a
process be visible at: /proc/<pid>/sys, and with a compat symlink
from /proc/sys ->  /proc/self/sys.

Just like has already been done with /proc/net.

1) On one hand it looks logical, that any nested dentries in /proc are tied to 
pid namespace. But on the other hand we have a lot of tunables in /proc/net, 
/proc/sys, etc. which have nothing with processes or whatever similar.
2) currently /proc processes directories (i.e. /proc/1/, etc) depends on mount 
maker context. But /proc/sys and /proc/net doesn't. This looks weird and 
despondently, from my pow. What do you think about it?

And what do you think about "conteinerization" of /proc contents in the way like 
"sysfs" was done?
Implementing /proc "conteinerization" in this way can give us great flexibility.
For example, /proc/net (and /proc/sys/sunrpc) depends on mount owner net 
namespace, /proc/sysvipc depends on mount owner ipc namespace, etc.
And this approach doesn't break backward compatibility as well.

Semantically this should be easy to understand, and about as backwards
compatible as it gets.

Eric

-- 
Best regards,
Stanislav Kinsbursky
--
To unsubscribe from this list: send the line "unsubscribe linux-nfs" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html