Kirill Korotaev <[email protected]> writes:
> After checking proposed yours, Eric and vserver solutions, I must say that these
> all are hacks.
> If we want to virtualize sysctl we need to do it in honest way:
> multiple sysctl trees, which can be different in different namespaces.
> For example, one namespace can see /proc/sys/net/route and the other one
> not.
At least a different copy of /proc/sys/net/route :)
> Introducing helpers/handlers etc. doesn't fully solve the problem of
> visibility of different parts of sysctl tree and it's access rights.
I need to look a little deeper but I think if we add two helper
functions: One that returns the address of a value based upon our state,
and another that returns a subdirectory based upon our state I think we
should be ok.
Both of them taking a struct task_struct argument so we can make the decision
what to show based upon the calling process.
> Another example, the same network device can present in 2 namespaces and these
> are dynamically(!) created entries in sysctl.
>
> So we need to address actually 2 issues:
> - ability to limit parts of sysctl tree visibility to namespace
> - ability to limit/change sysctl access rights in namespace
>
> You can check OpenVZ for cloning sysctl tree code. It is not clean, nor elegant,
> but can be cleanuped.
Sounds like a decent idea.
What I have found so far with access rights is that if you dig deep enough
you don't need magic to make it safe. But this may only be because I have
not hit something that is fundamentally different.
Eric
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [email protected]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[Index of Archives]
[Kernel Newbies]
[Netfilter]
[Bugtraq]
[Photo]
[Stuff]
[Gimp]
[Yosemite News]
[MIPS Linux]
[ARM Linux]
[Linux Security]
[Linux RAID]
[Video 4 Linux]
[Linux for the blind]
[Linux Resources]
