Quoting Miklos Szeredi ([EMAIL PROTECTED]):
> > > Thinking a bit more about this, I'm quite sure most users wouldn't
> > > even want private namespaces. It would be enough to
> > >
> > > chroot /share/$USER
> > >
> > > and be done with it.
> > >
> > > Private namespaces are only good for keep
On Fri, Apr 13, 2007 at 01:58:59PM +0200, Miklos Szeredi wrote:
> > On Wed, 2007-04-11 at 12:44 +0200, Miklos Szeredi wrote:
> > > > 1. clone the master namespace.
> > > >
> > > > 2. in the new namespace
> > > >
> > > > move the tree under /share/$me to /
> > > > for each ($user,
Greg KH <[EMAIL PROTECTED]> writes:
> On Fri, Apr 06, 2007 at 10:48:42AM -0600, Eric W. Biederman wrote:
>>
>> While shadow directories appear to be a good idea, the current scheme
>> of controlling their creation and destruction outside of sysfs appears
>> to be a locking and maintenance nightma
On Fri, Apr 06, 2007 at 10:48:42AM -0600, Eric W. Biederman wrote:
>
> While shadow directories appear to be a good idea, the current scheme
> of controlling their creation and destruction outside of sysfs appears
> to be a locking and maintenance nightmare in the face of sysfs directories
> dynam
Jean-Pierre Dion wrote:
> Hi Pavel,
>
> I have been implied in the work for the
> memory controller of res groups a few months ago.
>
> I see that you propose to modify the struct
> page to point to rss container struct.
> This has made some debate because of the struct
> page size increase, but
"Serge E. Hallyn" <[EMAIL PROTECTED]> writes:
> Quoting Miklos Szeredi ([EMAIL PROTECTED]):
>> > Given the existence of shared subtrees allowing/denying this at the mount
>> > namespace level is silly and wrong.
>> >
>> > If we need more than just the filesystem permission checks can we
>> > make
> > Thinking a bit more about this, I'm quite sure most users wouldn't
> > even want private namespaces. It would be enough to
> >
> > chroot /share/$USER
> >
> > and be done with it.
> >
> > Private namespaces are only good for keeping a bunch of mounts
> > referenced by a group of processes
Quoting Miklos Szeredi ([EMAIL PROTECTED]):
> > Given the existence of shared subtrees allowing/denying this at the mount
> > namespace level is silly and wrong.
> >
> > If we need more than just the filesystem permission checks can we
> > make it a mount flag settable with mount and remount that
Quoting Miklos Szeredi ([EMAIL PROTECTED]):
> > On Wed, 2007-04-11 at 12:44 +0200, Miklos Szeredi wrote:
> > > > 1. clone the master namespace.
> > > >
> > > > 2. in the new namespace
> > > >
> > > > move the tree under /share/$me to /
> > > > for each ($user, $what, $how) {
> > >
> On Wed, 2007-04-11 at 12:44 +0200, Miklos Szeredi wrote:
> > > 1. clone the master namespace.
> > >
> > > 2. in the new namespace
> > >
> > > move the tree under /share/$me to /
> > > for each ($user, $what, $how) {
> > > move /share/$user/$what to /$what
> > > if ($
* [EMAIL PROTECTED] <[EMAIL PROTECTED]> wrote:
Hi folks,
> If it needs to support OpenVZ quickly, it would be great if the
> userland control code is available in a library format under the
> LGPL, whereas the utilities can still be GPL.
I'm not an author of ovz, so I don't take part in th
> Given the existence of shared subtrees allowing/denying this at the mount
> namespace level is silly and wrong.
>
> If we need more than just the filesystem permission checks can we
> make it a mount flag settable with mount and remount that allows
> non-privileged users the ability to create mo
> question: how is mounting filesystems (loopback,
> fuse, etc) secured in such way that the user
> cannot 'create' device nodes with 'unfortunate'
> permissions?
All unprivileged mounts have "nosuid,nodev" added to their options.
Miklos
___
Containers
13 matches
Mail list logo
