Quoting Pavel Machek (pavel@ucw.cz):
quoted text
> > 
> > Pavel Machek wrote:
> > > > It is true that namespace may differ between processes,
> > > > but I think that that is the matter of how to restrict namespace manipulation operations.
> > > > As I said, a system can't survive if namespace is madly manipulated.
> > > > To keep the system workable, /bin/ must be the directory for binary programs,
> > > > /etc/ must be the directory for configuration files, and so on in all namespaces.
> > > 
> > > Ehm? Where did you get those ideas?
> > > 
> > > I'm free to name my directories any way I want, and keep config files
> > > in /pavlix_config, thank you... There is even distro that does
> > > something like that, IIRC...
> > > 
> > We can make processes have different namespace by using clone() with CLONE_NEWNS.
> > But even if some process got a different namespace, it need to follow conventional rules.
> > Optional files (e.g. /pavlix_config) need not to follow conventional rules.
> > What I'm talking about is essetial files (e.g. /bin/sh and
> > /etc/passwd).
> 
> Why would I need to follow rules?
> 
> > Can your system continue running even if essetial files are not in place
> > (like /bin/sh moved to /etc/sh and /etc/passwd moved to /bin/passwd) ?
> 
> Why not? They are just a names, they can be changed as log as you
> change them everywhere. Which is rather easy for small
> systems... think openembedded.
> 									Pavel

This is getting silly - if you change them "everywhere" then you can
change them in your security profiles too :)

Anyway this thread has degenerated again.

Crispin, thanks for posting those use cases.

Now the next step IMO is for someone (Tetsuo?) to take one of those use
cases and run through each of the four (was it 4?) proposed methods for
handling the pathnames.  One paragraph describing how the use case in
general would be handled, then a list of shortcomings for the solution.

-serge
--
To unsubscribe from this list: send the line "unsubscribe linux-fsdevel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html