"Serge E. Hallyn" writes:
> Quoting Eric W. Biederman (ebied...@xmission.com):
>> Adam Richter writes:
>>
>> > On Linux 4.8-rc1 through 4-8-rc6 (latest rc), lxc fails start to
>> > Ubuntu 16.04 and Centos 7 containers [1], unless I first run
>
"Serge E. Hallyn" writes:
> A common way for daemons to run with minimal privilege is to start as root,
> perhaps setuid-root, choose a desired capability set, set PR_SET_KEEPCAPS,
> then change uid to non-root. A simpler way to achieve this is to set file
> capabilities on a not-setuid-root bin
"Serge E. Hallyn" writes:
> On Mon, Nov 16, 2015 at 04:24:27PM -0600, Eric W. Biederman wrote:
>> Similary have you considered what it required to be able to safely set
>> FS_USERNS_MOUNT?
>
> I pushed the one patch which I feel is needed to my branch (it
"Serge E. Hallyn" writes:
> On Mon, Nov 16, 2015 at 09:50:55PM +0100, Richard Weinberger wrote:
>> Am 16.11.2015 um 21:46 schrieb Serge E. Hallyn:
>> > On Mon, Nov 16, 2015 at 09:41:15PM +0100, Richard Weinberger wrote:
>> >> Serge,
>> >>
>> >> On Mon, Nov 16, 2015 at 8:51 PM, wrote:
>> >>> To
"Carlos O'Donell" writes:
> On 08/06/2014 05:46 PM, Serge Hallyn wrote:
>> Quoting Eric W. Biederman (ebied...@xmission.com):
>>> Serge Hallyn writes:
>
> Reviving this super-old discussion because it went in a direction
> that I didn't
"Carlos O'Donell" writes:
> On 05/16/2015 01:03 AM, Eric W. Biederman wrote:
>>> Such reasons would help inform a new API design.
>>
>> So we could specify flags that create namespaces aka: CLONE_NEWNS,
>> CLONE_NEWUTS, CLONE_NEWIPC, CLONE_NEWU
Andy Lutomirski writes:
> On Mon, Sep 29, 2014 at 4:22 PM, Eric W. Biederman
> wrote:
>> Andy Lutomirski writes:
>>
>>> To me, this smells like MNT_DETACH does something awful when there are
>>> mounts under the detached mount.
>>>
>>> F
Andy Lutomirski writes:
> To me, this smells like MNT_DETACH does something awful when there are
> mounts under the detached mount.
>
> For example:
>
> mount --rbind / /mnt
> umount -l /mnt
>
> does *not* end well on my system. I find it hard to believe that this
> behavior is intentional.
Hmm
Andy Lutomirski writes:
> On Mon, Sep 29, 2014 at 3:46 PM, Serge Hallyn wrote:
>> Quoting Andy Lutomirski (l...@amacapital.net):
>>> On Mon, Sep 29, 2014 at 2:46 PM, Serge Hallyn
>>> wrote:
>>> I'm not sure that "/" is well-defined. You have oldroot mounted on
>>
>> Whoa. Seems you're right.
riya khanna writes:
> What kind of existing multiplexers could be used? Is there one for fb? We have
> evdev abstractions for input in place already.
We have X and Wayland/Weston and pulse audio and doubtless more that I
am not aware of.
For video a lot of working is going into compositing and
riya khanna writes:
> Is there a plan or work-in-progress to add namespace tags to other
> classes in sysfs similar to net? Does it make sense to add namespace
> tags to kobjects?
Currently the a general nack from gregkh on such work.
Given that sysfs is almost never a fast path I suspect it ma
Riya Khanna writes:
> On Sep 24, 2014, at 12:43 PM, Eric W. Biederman wrote:
>
>> Serge Hallyn writes:
>>
>>> Isolation is provided by the devices cgroup. You want something more
>>> than isolation.
>>>
>>> Quoting riya khanna (riyakha
Serge Hallyn writes:
> Isolation is provided by the devices cgroup. You want something more
> than isolation.
>
> Quoting riya khanna (riyakhanna1...@gmail.com):
>> My use case for having device namespaces is device isolation. Isn't what
>> namespaces are there for (as I understand)?
Namespaces
riya khanna writes:
> (Please pardon multiple emails, artifact of merging all separate
> conversations)
>
> Thanks for your feedback!
>
> Letting the kernel know about what devices a container could access (based on
> device cgroups) and having devtmpfs in the kernel create device nodes for a
>
Serge Hallyn writes:
> Quoting Eric W. Biederman (ebied...@xmission.com):
>> It would be nice if at least malloc and C++ new were safe (and
>> documented as safe) after fork in a pthread environment. That would go
>> a long ways to allowing running interesting set up code
While talking about pain points there is a very large one. In short
pthreads break fork().
At least according to the open group after fork (when more than one
pthread is active) and by extension clone(CLONE_NEW...) it is only safe
to call async-signal-safe functions. The rationale being that so
Serge Hallyn writes:
> Quoting Eric W. Biederman (ebied...@xmission.com):
>> Serge Hallyn writes:
>>
>> > Quoting Eric W. Biederman (ebied...@xmission.com):
>> >>
>> >> Serge Hallyn writes:
>> >> > Quoting Carlos O'Donell (
Serge Hallyn writes:
> Quoting Eric W. Biederman (ebied...@xmission.com):
>>
>> Serge Hallyn writes:
>> > Quoting Carlos O'Donell (car...@redhat.com):
>> >> There was a complaint a while back from someone working
>> >> on containers about
Serge Hallyn writes:
> Quoting Carlos O'Donell (car...@redhat.com):
>> There was a complaint a while back from someone working
>> on containers about glibc PID caching. I recently received
>> another request to provide userspace with a way to reset
>> any PID or TID caches to make clone-based san
Seth Forshee writes:
> On Mon, Jul 21, 2014 at 03:09:14PM +0200, Miklos Szeredi wrote:
>> On Mon, Jul 21, 2014 at 2:47 PM, Seth Forshee
>> wrote:
>> > On Fri, Jul 18, 2014 at 05:33:23PM +0200, Miklos Szeredi wrote:
>> >> On Mon, Jul 14, 2014 at 9:18 PM, Seth Forshee
>> >> wrote:
>> >> > Update
James Bottomley writes:
> On Tue, 2014-06-03 at 10:54 -0700, Eric W. Biederman wrote:
>>
>> 90% of that work is already done.
>>
>> As long as we don't plan to support XFS (as it XFS likes to expose it's
>> implementation details to userspace) it s
--
>>>>> Hash: SHA1
>>>>>
>>>>> On 05/29/2014 01:06 PM, Eric W. Biederman wrote:
>>>>>> Marian Marinov writes:
>>>>>>
>>>>>>> Hello,
>>>>>>>
>>>>>>> I have
Serge Hallyn writes:
> Quoting Pavel Emelyanov (xe...@parallels.com):
>> On 05/29/2014 07:32 PM, Serge Hallyn wrote:
>> > Quoting Marian Marinov (m...@1h.com):
>> >> We are not using NFS. We are using a shared block storage that offers us
>> >> snapshots. So provisioning new containers is
>> >>
Marian Marinov writes:
> Hello,
>
> I have the following proposition.
>
> Number of currently running processes is accounted at the root user
> namespace. The problem I'm facing is that multiple
> containers in different user namespaces share the process counters.
That is deliberate.
> So if c
"Serge E. Hallyn" writes:
>> I was aware of FUSE but hadn't ever looked at it much. Looking at it
>> now, this isn't going to satisfy any of the use cases I know about,
>> which are wanting to use filesystems supported in-kernel (isofs, ext*).
>> I don't see that any of these have a FUSE implement
Serge Hallyn writes:
> Quoting Eric W. Biederman (ebied...@xmission.com):
>>
>>
>> >> Ultimately the technical challenge is how do we create a block device
>> >> that is safe for a user who does not have any capabilities to use, and
>> >> what
>> Ultimately the technical challenge is how do we create a block device
>> that is safe for a user who does not have any capabilities to use, and
>> what can we do with that block device to make it useful.
>
> Yes, and I'd like to get started solving those challenges. But I also
> don't think we
Seth Forshee writes:
> What I set out for was feature parity between loop devices in a secure
> container and loop devices on the host. Since some operations currently
> check for system-wide CAP_SYS_ADMIN, the only way I see to accomplish
> this is to push knowledge of the user namespace farther
Greg Kroah-Hartman writes:
> On Fri, May 16, 2014 at 01:49:59AM +, Serge Hallyn wrote:
>> > I think having to pick and choose what device nodes you want in a
>> > container is a good thing. Becides, you would have to do the same thing
>> > in the kernel anyway, what's wrong with userspace ma
Serge Hallyn writes:
> Quoting Stephan Sachse (ste.sac...@gmail.com):
>> w/ userns:
>> [root@fedora2 ~]# setcap 'cap_net_admin,cap_net_raw+ep' /usr/bin/ping
>> Failed to set capabilities on file `/usr/bin/ping' (Operation not permitted)
>> [root@fedora2 ~]# id
>> uid=0(root) gid=0(root) groups=0(
Stéphane Graber writes:
> The problem obviously comes from those two error messages which say that
> setns back to the original namespace failed.
>
> I can't think of a nice way around this particular limitation nor am I
> convinced that there is any safe way to fix that at the kernel level.
> (C
31 matches
Mail list logo
