All of lore.kernel.org
 help / color / mirror / Atom feed
From: Ram Pai <linuxram@us.ibm.com>
To: Miklos Szeredi <miklos@szeredi.hu>
Cc: Al Viro <viro@ftp.linux.org.uk>,
	torvalds@osdl.org, linux-kernel@vger.kernel.org,
	linux-fsdevel@vger.kernel.org
Subject: Re: [PATCH 2/18] cleanups and bug fix in do_loopback()
Date: Wed, 09 Nov 2005 16:51:08 -0800	[thread overview]
Message-ID: <1131583868.5400.685.camel@localhost> (raw)
In-Reply-To: <E1EZxHb-00031A-00@dorka.pomaz.szeredi.hu>

On Wed, 2005-11-09 at 13:15, Miklos Szeredi wrote:
> >  Yes there is some contradiction of some sorts on this. private-ness
> > means that the namespace must _not_ be accesible to processes
> > in other namespace. But 'file descriptor sent between two processes in
> > different namespaces' seems to break that guarantee.  
> 
> So..., are we going to check namespace in every file operation?  How
> much do you want to bet, that it won't break any applications?

I don't know. May be there are applications out there that depend on
this. It depends on the definition of private-ness of namespace. 
I am just saying that you raise a valid point.

I am not sure if fixing this behavior hurts more or soothes more,

Any idea?
RP


> 
> > > Also with ptrace() you can still access other process's namespace, so
> > > proc_check_root() is also too strict (or ptrace() too lax).
> > 
> > same here.
> 
> You mean, that ptrace() _is_ too lax?  Adding a namespace check to
> ptrace might well cause grief too.
> 
> The real question is, how private do we want the namespace to be.  I
> don't believe, we need to make it any more private than it currently
> is.
> 
> Miklos


      reply	other threads:[~2005-11-10  0:51 UTC|newest]

Thread overview: 7+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2005-11-08  2:01 [PATCH 2/18] cleanups and bug fix in do_loopback() Al Viro
2005-11-08  6:59 ` Miklos Szeredi
2005-11-08  8:46   ` Ram Pai
2005-11-08  9:28     ` Miklos Szeredi
2005-11-09 19:08       ` Ram Pai
2005-11-09 21:15         ` Miklos Szeredi
2005-11-10  0:51           ` Ram Pai [this message]

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=1131583868.5400.685.camel@localhost \
    --to=linuxram@us.ibm.com \
    --cc=linux-fsdevel@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=miklos@szeredi.hu \
    --cc=torvalds@osdl.org \
    --cc=viro@ftp.linux.org.uk \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.