mirror of https://lore.kernel.org/lkml/
 help / color / mirror / Atom feed
From: Al Viro <viro@parcelfarce.linux.theplanet.co.uk>
To: Florian Weimer <fw@deneb.enyo.de>
Cc: Janak Desai <janak@us.ibm.com>,
	sds@tycho.nsa.gov, linuxram@us.ibm.com, ericvh@gmail.com,
	dwalsh@redhat.com, jmorris@redhat.com, akpm@osdl.org,
	torvalds@osdl.org, gh@us.ibm.com, linux-fsdevel@vger.kernel.org,
	linux-kernel@vger.kernel.org
Subject: Re: [PATCH 0/3] New system call, unshare
Date: Tue, 23 Aug 2005 07:18:16 +0100	[thread overview]
Message-ID: <20050823061815.GE9322@parcelfarce.linux.theplanet.co.uk> (raw)
In-Reply-To: <878xz9dgv4.fsf@mid.deneb.enyo.de>

On Wed, Aug 10, 2005 at 04:08:31PM +0200, Florian Weimer wrote:
> * Janak Desai:
> 
> > With unshare, namespace setup can be done using PAM session
> > management functions without patching individual commands.
> 
> I don't think it's a good idea to use security-critical code well
> without its original specification.  Clearly the current situation
> sucks, but this is mainly a lack of PAM functionality, IMHO.

Eh?  We are talking about a primitive that has far more uses than
PAM.  This is a missing piece of the stuff done by clone() and fork():
each task is a virtual machine with sharable components.  We can
get a copy of machine  with arbitrary set of components replaced with
private copies.  That's what clone() and fork() do.  The thing missing
from that set is taking a component (VM, descriptors, etc.) of process
itself and making it private.  The same thing we do on fork(), but
without creating a new process.

FWIW, I'm OK with that.  IIRC, Linus ACKed the concept some time ago.
PAM is one obvious use, but there's are other situations where the lack
of that primitive is inconvenient...

  parent reply	other threads:[~2005-08-23  6:15 UTC|newest]

Thread overview: 6+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2005-08-08 13:28 Janak Desai
2005-08-10 14:08 ` Florian Weimer
2005-08-10 14:18   ` serue
2005-08-10 15:05     ` Janak Desai
2005-08-23  6:18   ` Al Viro [this message]
2005-09-07 17:34     ` Janak Desai

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=20050823061815.GE9322@parcelfarce.linux.theplanet.co.uk \
    --to=viro@parcelfarce.linux.theplanet.co.uk \
    --cc=akpm@osdl.org \
    --cc=dwalsh@redhat.com \
    --cc=ericvh@gmail.com \
    --cc=fw@deneb.enyo.de \
    --cc=gh@us.ibm.com \
    --cc=janak@us.ibm.com \
    --cc=jmorris@redhat.com \
    --cc=linux-fsdevel@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linuxram@us.ibm.com \
    --cc=sds@tycho.nsa.gov \
    --cc=torvalds@osdl.org \
    /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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox

Powered by JetHome