Enrico Weigelt writes:
> On 13.02.2018 22:12, Enrico Weigelt wrote:
>
> CC @contain...@lists.linux-foundation.org
>
>> Hi folks,
>>
>>
>> I'm currently trying to implement plan9 semantics on Linux and
>> yet sorting out how to do the mount namespace handling.
>>
>> On plan9, any unprivileged proc
On 2018-02-14, Enrico Weigelt wrote:
> But still I wonder whether user_ns really solves my problem, as I don't
> want to create sandboxed users, but only private namespaces just like
> on Plan9.
On Linux you need to have CAP_SYS_ADMIN (in the user_ns that owns your
current mnt_ns) in order to mou
On 14.02.2018 19:12, Richard Weinberger wrote:
BTW: Your issue is fixed/known. Just checked.
aha, on 1.2.28 ... I'll have to upgrade.
--mtx
--
Enrico Weigelt, metux IT consult
Free software and Linux embedded engineering
i...@metux.net -- +49-151-27565287
Am Mittwoch, 14. Februar 2018, 19:01:52 CET schrieb Enrico Weigelt:
> On 14.02.2018 18:50, Richard Weinberger wrote:
> >> hmm, now it works, but only when strace'ing it.
> >> that's really strange.
> >
> > On my box, with my patch applied, also busybox works now.
>
> hmm, w/o strace, too ?
Sure.
On 14.02.2018 18:50, Richard Weinberger wrote:
hmm, now it works, but only when strace'ing it.
that's really strange.
On my box, with my patch applied, also busybox works now.
hmm, w/o strace, too ?
Which version are you using ? I've got 1.27.2
But still I wonder whether user_ns really sol
Am Mittwoch, 14. Februar 2018, 18:21:12 CET schrieb Enrico Weigelt:
> On 14.02.2018 16:17, Richard Weinberger wrote:
> > From taking a *very* quick look into busybox source, I suspect this
> > should fix>
> > it:
> >
> > diff --git a/util-linux/unshare.c b/util-linux/unshare.c
> > index 875e3f8
On 14.02.2018 16:17, Richard Weinberger wrote:
From taking a *very* quick look into busybox source, I suspect this should fix
it:
diff --git a/util-linux/unshare.c b/util-linux/unshare.c
index 875e3f86e304..3f59cf4d27c2 100644
--- a/util-linux/unshare.c
+++ b/util-linux/unshare.c
@@ -350,9 +35
Enrico,
Am Mittwoch, 14. Februar 2018, 16:02:18 CET schrieb Enrico Weigelt:
> stat64("/etc/busybox.conf", {st_mode=S_IFREG|0644, st_size=198, ...}) = 0
busybox...
> brk(NULL) = 0x58000
> brk(0x79000)= 0x79000
> open("/etc/busybox.conf", O
On 14.02.2018 15:19, Richard Weinberger wrote:
Works here(tm).
Can you debug it? Maybe we miss something obvious.
daemon@alphabox:~ strace unshare -U -r --setgroups=deny
execve("/bin/unshare", ["unshare", "-U", "-r", "--setgroups=deny"],
0x7ee51e0c /* 11 vars */) = 0
brk(NULL)
Am Mittwoch, 14. Februar 2018, 15:03:55 CET schrieb Enrico Weigelt:
> On 14.02.2018 13:53, Richard Weinberger wrote:
> > It does what you ask it for. > Also see the --setgroups switch.> AFAICT
> > --setgroups=deny is the new
> default, then your command line should just> work. Maybe your unshare
>
On 14.02.2018 13:53, Richard Weinberger wrote:
It does what you ask it for. > Also see the --setgroups switch.> AFAICT --setgroups=deny is the new
default, then your command line should just> work. Maybe your unshare
tool is too old.
Also doesn't help:
daemon@alphabox:~ unshare -U -r --setgro
Enrico,
Am Mittwoch, 14. Februar 2018, 13:38:48 CET schrieb Enrico Weigelt:
> On 14.02.2018 12:30, Richard Weinberger wrote:
> > On Wed, Feb 14, 2018 at 12:27 PM, Enrico Weigelt wrote:
> >> On 14.02.2018 11:24, Aleksa Sarai wrote:
> >>> What distribution are you using and which release?
> >>
> >
On 14.02.2018 12:30, Richard Weinberger wrote:
On Wed, Feb 14, 2018 at 12:27 PM, Enrico Weigelt wrote:
On 14.02.2018 11:24, Aleksa Sarai wrote:
What distribution are you using and which release?
On a self-compiled system.
Forgot to enable namespaces in the kernel. Now it seems to work
as
On Wed, Feb 14, 2018 at 12:27 PM, Enrico Weigelt wrote:
> On 14.02.2018 11:24, Aleksa Sarai wrote:
>
>> What distribution are you using and which release?
>
>
> On a self-compiled system.
>
> Forgot to enable namespaces in the kernel. Now it seems to work
> as root, but not as an unprivileged user
On 14.02.2018 11:24, Aleksa Sarai wrote:
What distribution are you using and which release?
On a self-compiled system.
Forgot to enable namespaces in the kernel. Now it seems to work
as root, but not as an unprivileged user:
daemon@alphabox:~ unshare -r -U
unshare: can't open '/proc/self/se
On 2018-02-14, Enrico Weigelt wrote:
> On 14.02.2018 04:54, Aleksa Sarai wrote:
>
> > It depends how old your kernel is and what distro you use. Arch Linux >
> > disables user namespaces entirely, Debian requires that you set a
> sysctl> to enable unprivileged user namespaces, and RHEL requires y
On 14.02.2018 04:54, Aleksa Sarai wrote:
It depends how old your kernel is and what distro you use. Arch Linux > disables user namespaces entirely, Debian requires that you set a
sysctl> to enable unprivileged user namespaces, and RHEL requires you to
set> both a sysctl and a kernel boot-flag.
On 2018-02-14, Enrico Weigelt wrote:
> On 13.02.2018 22:27, Aleksa Sarai wrote:
>
> > You can do this by creating a new user namespace (CLONE_NEWUSER), which
> > then gives you the required permissions to create other namespaces
> > (CLONE_NEWNS). This is how "rootless containers" or unprivileged
On 13.02.2018 22:27, Aleksa Sarai wrote:
You can do this by creating a new user namespace (CLONE_NEWUSER), which
then gives you the required permissions to create other namespaces
(CLONE_NEWNS). This is how "rootless containers" or unprivileged
containers operate.
hmm, unshare -U doesn't work
On 2018-02-13, Enrico Weigelt wrote:
> On 13.02.2018 22:12, Enrico Weigelt wrote:
> > I'm currently trying to implement plan9 semantics on Linux and
> > yet sorting out how to do the mount namespace handling.
> >
> > On plan9, any unprivileged process can create its own namespace
> > and mount/bi
On 13.02.2018 22:12, Enrico Weigelt wrote:
CC @contain...@lists.linux-foundation.org
Hi folks,
I'm currently trying to implement plan9 semantics on Linux and
yet sorting out how to do the mount namespace handling.
On plan9, any unprivileged process can create its own namespace
and mount/bind
Hi folks,
I'm currently trying to implement plan9 semantics on Linux and
yet sorting out how to do the mount namespace handling.
On plan9, any unprivileged process can create its own namespace
and mount/bind at will, while on Linux this requires CAP_SYS_ADMIN.
What is the reason for not allowi
22 matches
Mail list logo
