Buildah: "Buildah Tutorial 1" should emphasize what needs to be run as root
All of the commands in that tutorial I've seen so far are being shown as run as root but, given the emphasis these days on running as non-root, the tutorial should probably distinguish which commands can be run as a normal user.
In fact, it seems most of them can, until you get to:
# scratchmnt=$(buildah mount $newcontainer)
That one does appear to need to be run as root, is that correct? Is it not worth making sure those distinctions are clear?
rpjday
All 47 comments
Specifically, I refer to this early claim: "First step is to install Buildah. Run as root because you will need to be root for running Buildah commands:" Not true -- most of those "buildah" commands do not require root privilege, and the few that do should be clearly identified.
rpjday
on 3 Apr 2019
@rpjday when these tutorials were written, they running rootless was something that was being talked about, but was not on the immediate horizon. A touch up of this tutorial and others is probably warranted now. @ipbabble do you have the time to take a whack at it?
TomSweeneyRedHat
on 3 Apr 2019
I will take a whack at this later this week. Thanks. Please remind me @TomSweeneyRedHat
ipbabble
on 3 Apr 2019
Speaking from a position of ignorance, what should happen if you mix root and non-root commands in the same example? Is there a chance things will be spread between the root and non-root directories? Should mixing root and non-root commands work?
rpjday
on 3 Apr 2019
No root and non-root do not share storage or containers.
We should show running the example both as root and running it in nonroot. Hint, Non Root first do
buildah unshare
rhatdan
on 3 Apr 2019
This is probably a dumb question, but what I'm unclear on is what happens if you create some sort of object as root, then try to access or query it as non-root, will there be any confusion as to where to look for it? I think I'm just confused as to what the difference between what root and non-root really mean. Oh, and I recall that, even running mostly as non-root, there is the occasional command that must be run as root, I thought it was "buildah mount".
I think I just need to go back and read more.
rpjday
on 3 Apr 2019
I thought we documented this somewhere.
Here is the issue.
https://github.com/containers/buildah/issues/1279
rhatdan
on 3 Apr 2019
man buildah mount
...
When running in rootless mode, mount runs in a different namespace so that the mounted volume might not be accessible from the host when using a driver different than vfs. To be able to access the
file system mounted, you might need to create the mount namespace separately as part of buildah unshare. In the environment created with buildah unshare you can then use buildah mount and have
access to the mounted file system.
I'd like to add that it is really confusing whether buildah is without any sort of root access or a "privileged" container. I can't seem to find a place that answers this concisely and completely and builds my intuition. Issues like #1335 kind of mirror my lack of understanding/frustration -- does buildah build containers without root permissions or not (assuming seccomp is not an issue)?
From what I understand, the key to making buildah work in a non-root environments is the use of:
- user namespaces
- FUSE (userspace filesystems)
I've enabled user namespaces unprivileged user names spaces via sysctl:
sudo sysctl -w kernel.unprivileged_userns_clone=1
FUSE libraries are installed on my distro -- yet when I attempt to run buildah from inside an unprivileged fedora or buildah/buildah container, I get this error:
host $ docker run -v /tmp/test:/var/lib/containers --rm -it fedora /bin/bash
[root@bf1dc956424b containers]# dnf install buildah
[root@bf1dc956424b containers]# buildah bud .
Error during unshare(CLONE_NEWUSER): Operation not permitted
ERRO[0000] error parsing PID "": strconv.Atoi: parsing "": invalid syntax
ERRO[0000] (unable to determine exit status)
As a new user it's kind of unclear to me what I'm doing wrong here, does the "rootless" building that buildah is doing refer to after you've started a container as root on the host system already? Am I missing options? It seems like I need to be running with the alternate isolation mode (chroot) and possibly forcing buildah to use a FUSE driver to get a truly "rootless" build?
If I run docker run with --privileged it will work spectacularly which is great, but I am looking into buildah because it seems to offer a way to not have to use a privileged container to start with.
[EDIT] - I want to add that looking through github issues, blog posts, and release notes (like 1.5 for example), It's not 100% clear what the difference between "rootless mode" and any other mode.
[EDIT2] - A related issue I also came across suggests that maybe I should be using BUILDAH_ISOLATION set to rootless? I double checked and I am using a version of buildah that is new enough to have the fix merged -- 1.8.2 IIRC yet that didn't work for me either.
t3hmrman
on 24 May 2019
ping @ipbabble
TomSweeneyRedHat
on 29 May 2019
@ipbabble Are you able to work on this?
rhatdan
on 8 Jun 2019
I have not being. But I will get to it this week.
Sent from my iPhone
On Jun 8, 2019, at 12:58 PM, Daniel J Walsh notifications@github.com wrote:
@ipbabble Are you able to work on this?
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub, or mute the thread.
ipbabble
on 9 Jun 2019
@ipbabble Did you ever get a chance to look at this?
@TomSweeneyRedHat Do you have time to take this on?
rhatdan
on 20 Jun 2019
So this looks like your running buildah bud inside a Fedora container run
by docker that is mounting a temp directory to /var/lib/containers. However
I don’t see any Dockerfile in this containers to know what it is that you
are trying to run buildah bud on. The error suggests a syntax error in the
Dockerfile but it is not clear there is a Dockerfile present (seeing as you
just ran buildah bud on a unknown Fedora container.
Can I have more details?
William
On Thursday, June 20, 2019, Daniel J Walsh notifications@github.com wrote:
@ipbabble https://github.com/ipbabble Did you ever get a chance to look
at this?
@TomSweeneyRedHat https://github.com/TomSweeneyRedHat Do you have time
to take this on?—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
https://github.com/containers/buildah/issues/1469?email_source=notifications&email_token=AAJ6TAIS2VXESCM3HKZ6F7LP3NGJPA5CNFSM4HDHCHM2YY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGODYE4P7A#issuecomment-503957500,
or mute the thread
https://github.com/notifications/unsubscribe-auth/AAJ6TAOKU5SNEVZXHVA7EMDP3NGJPANCNFSM4HDHCHMQ
.
--
Sent from Gmail Mobile on iPhone
ipbabble
on 27 Jun 2019
@ipbabble I don't think that has anything to do with the Dockerfile.
I tried with a minimal Dockerfile:
FROM alpine:latest
If I run buildah inside a privileged container docker run --rm -it -v "$(pwd):/build:rw" --privileged quay.io/buildah/stable everything works as expected:
$ buildah bud /build
STEP 1: FROM alpine:latest
Getting image source signatures
Copying blob 9d48c3bd43c5 done
Copying config 9617696764 done
Writing manifest to image destination
Storing signatures
STEP 2: COMMIT
961769676411f082461f9ef46626dd7a2d1e2b2a38e6a44364bcbecf51e66dd4
If I run it inside a unprivileged container docker run --rm -it -v "$(pwd):/build:rw" quay.io/buildah/stable it get the same error as @t3hmrman :
$ buildah bud /build
Error during unshare(CLONE_NEWUSER): Operation not permitted
ERRO[0000] error parsing PID "": strconv.Atoi: parsing "": invalid syntax
ERRO[0000] (unable to determine exit status)
Note that I have already setup sysctl -w kernel.unprivileged_userns_clone=1
bachp
on 21 Aug 2019
I will do my best to look at this tomorrow - Thurs.
-William
William G Henry
Senior Distinguished Engineer
Red Hat https://www.redhat.com
M: +17192716951 IM: ipbabble
https://www.redhat.com
On Wed, Aug 21, 2019 at 4:25 AM Pascal Bach notifications@github.com
wrote:
@ipbabble https://github.com/ipbabble I don't think that has anything
to do with the Dockerfile.I tried with a minimal Dockerfile:
FROM alpine:latest
If I run buildah inside a privileged container docker run --rm -it -v
"$(pwd):/build:rw" --privileged quay.io/buildah/stable everything works
as expected:$ buildah bud /build
STEP 1: FROM alpine:latest
Getting image source signatures
Copying blob 9d48c3bd43c5 done
Copying config 9617696764 done
Writing manifest to image destination
Storing signatures
STEP 2: COMMIT
961769676411f082461f9ef46626dd7a2d1e2b2a38e6a44364bcbecf51e66dd4If I run it inside a unprivileged container docker run --rm -it -v
"$(pwd):/build:rw" quay.io/buildah/stable it get the same error as
@t3hmrman https://github.com/t3hmrman :$ buildah bud /build
Error during unshare(CLONE_NEWUSER): Operation not permitted
ERRO[0000] error parsing PID "": strconv.Atoi: parsing "": invalid syntax
ERRO[0000] (unable to determine exit status)Note that I have already setup sysctl -w
kernel.unprivileged_userns_clone=1—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
https://github.com/containers/buildah/issues/1469?email_source=notifications&email_token=AAJ6TAOL3WIRFJJ3GZ7KFSDQFUJ2DA5CNFSM4HDHCHM2YY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGOD4ZGPWI#issuecomment-523397081,
or mute the thread
https://github.com/notifications/unsubscribe-auth/AAJ6TAPVTGPFWMIAUDEIX4LQFUJ2DANCNFSM4HDHCHMQ
.
ipbabble
on 21 Aug 2019
Add --device=/dev/fuse
rhatdan
on 21 Aug 2019
Works fine from podman
# podman run --device /dev/fuse --rm -it -v "$(pwd):/build:rw,Z" quay.io/buildah/stable buildah bud /build
STEP 1: FROM alpine
Getting image source signatures
Copying blob 9d48c3bd43c5 done
Copying config 9617696764 done
Writing manifest to image destination
Storing signatures
STEP 2: COMMIT
961769676411f082461f9ef46626dd7a2d1e2b2a38e6a44364bcbecf51e66dd4
Docker runs with a tigher seccomp the podman, so it blows up.
Disabling seccomp works
docker run --security-opt seccomp=unconfined --device /dev/fuse --rm -it -v "$(pwd):/build:rw,Z" quay.io/buildah/stable buildah bud /build
STEP 1: FROM alpine
Getting image source signatures
Copying blob 9d48c3bd43c5 done
Copying config 9617696764 done
Writing manifest to image destination
Storing signatures
STEP 2: COMMIT
961769676411f082461f9ef46626dd7a2d1e2b2a38e6a44364bcbecf51e66dd4
Also if you use podman's seccomp in docker it works.
docker run --security-opt seccomp=/usr/share/containers/seccomp.json --device /dev/fuse --rm -it -v "$(pwd):/build:rw,Z" quay.io/buildah/stable buildah bud /build
STEP 1: FROM alpine
Getting image source signatures
Copying blob 9d48c3bd43c5 done
Copying config 9617696764 done
Writing manifest to image destination
Storing signatures
STEP 2: COMMIT
961769676411f082461f9ef46626dd7a2d1e2b2a38e6a44364bcbecf51e66dd4
Podman secomp.json does not block mount syscall, which is needed to do the bind mounts when running buildah within a container.
rhatdan
on 21 Aug 2019
@rhatdan Indeed that seems to work. It would really be helpful to have this documented somewhere.
bachp
on 21 Aug 2019
I just wrote a recent blog on this.
https://developers.redhat.com/blog/2019/08/14/best-practices-for-running-buildah-in-a-container/
But this does not talk about Docker.
rhatdan
on 21 Aug 2019
At this point I am not sure what to do with this issue. @TomSweeneyRedHat WDYT?
rhatdan
on 21 Aug 2019
I think @ipbabble will be working on the doc tomorrow. Let's see what magic he whips up.
TomSweeneyRedHat
on 21 Aug 2019
New user here.
I have spent the pass 2 days trying to get my head around running buildah in my kubernetes cluster.
As mentioned https://developers.redhat.com/blog/2019/08/14/best-practices-for-running-buildah-in-a-container/ is very useful but it was pretty surprising to be able to run quay.io/buildah/stable:v1.11.2 on my kubernetes cluster but not locally on docker.
I had and still have issues with the basic build and push in a container and if interested I can open a different issue to describe which part of the doc is lacking.
benjamin-bergia
on 2 Oct 2019
This is strange. Can you tell us more about this buildah/stable:v1.11.2 ?
I assume you are pulling it down with Docker before trying to run it,
right? (just checking to eliminate some obvious gotchas)
I promised to work on the other issues but failed to do so because of
travel. I will spend time on this today.
-ipbabble
On Wed, Oct 2, 2019 at 8:28 AM ITChap notifications@github.com wrote:
New user here.
I have spent the pass 2 days trying to get my head around running buildah
in my kubernetes cluster.
As mentioned
https://developers.redhat.com/blog/2019/08/14/best-practices-for-running-buildah-in-a-container/
is very useful but it was pretty surprising to be able to run
quay.io/buildah/stable:v1.11.2 on my kubernetes cluster but not locally
on docker.I had and still have issues with the basic build and push in a container
and if interested I can open a different issue to describe which part of
the doc is lacking.—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
https://github.com/containers/buildah/issues/1469?email_source=notifications&email_token=AAJ6TALB3ZSI47JSOIC324LQMSVXTA5CNFSM4HDHCHM2YY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGOEAE6GQA#issuecomment-537518912,
or mute the thread
https://github.com/notifications/unsubscribe-auth/AAJ6TAO3FS5ZVX4FXFVW76TQMSVXTANCNFSM4HDHCHMQ
.
--
William G Henry
Senior Distinguished Engineer
Red Hat https://www.redhat.com
M: +17192716951 IM: ipbabble
https://www.redhat.com
ipbabble
on 2 Oct 2019
Most likely pulled the image from quay.io. https://quay.io/repository/buildah/stable?tab=tags
TomSweeneyRedHat
on 2 Oct 2019
@benjamin-bergia Thanks for the feedback and sorry for the troubles. I'd be very interested in hearing what parts of the docs are unclear or missing. Also if you expected to find them in a particular location and did not.
I'd also be interested to see how you tried to run that Buildah image in Docker and what the errors were that you ran into. If you could do that in a separate issue, that would be great or if you prefer subscribe to the Buildah mailing list ([email protected] with the word subscribe in the subject) and ask away there.
TomSweeneyRedHat
on 2 Oct 2019
Hi @TomSweeneyRedHat,
no need to apology, you guys built a great tool I like working with it.
I will create a new issue for the doc and regarding the issue I have the exact same than @t3hmrman and @bachp when running locally on my docker. Any other command than version seems to throw the following error:
$ buildah bud /build Error during unshare(CLONE_NEWUSER): Operation not permitted ERRO[0000] error parsing PID "": strconv.Atoi: parsing "": invalid syntax ERRO[0000] (unable to determine exit status)
It was a bit misleading, since, in my very limited understanding, I though that setting --userns='' would prevent the use of any namespace, but it didn't. I guess kubernetes ships with different default security settings than the docker packaged on my system.
benjamin-bergia
on 3 Oct 2019
Unshare being blocked is probably seccomp? I believe Capabilities and SELinux should allow it.
rhatdan
on 3 Oct 2019
I don't know if this helps but here is the /etc/docker/seccomp.json file from my testing cluster.
{
"defaultAction": "SCMP_ACT_ERRNO",
"archMap": [
{
"architecture": "SCMP_ARCH_X86_64",
"subArchitectures": [
"SCMP_ARCH_X86",
"SCMP_ARCH_X32"
]
},
{
"architecture": "SCMP_ARCH_AARCH64",
"subArchitectures": [
"SCMP_ARCH_ARM"
]
},
{
"architecture": "SCMP_ARCH_MIPS64",
"subArchitectures": [
"SCMP_ARCH_MIPS",
"SCMP_ARCH_MIPS64N32"
]
},
{
"architecture": "SCMP_ARCH_MIPS64N32",
"subArchitectures": [
"SCMP_ARCH_MIPS",
"SCMP_ARCH_MIPS64"
]
},
{
"architecture": "SCMP_ARCH_MIPSEL64",
"subArchitectures": [
"SCMP_ARCH_MIPSEL",
"SCMP_ARCH_MIPSEL64N32"
]
},
{
"architecture": "SCMP_ARCH_MIPSEL64N32",
"subArchitectures": [
"SCMP_ARCH_MIPSEL",
"SCMP_ARCH_MIPSEL64"
]
},
{
"architecture": "SCMP_ARCH_S390X",
"subArchitectures": [
"SCMP_ARCH_S390"
]
}
],
"syscalls": [
{
"names": [
"accept",
"accept4",
"access",
"alarm",
"alarm",
"bind",
"brk",
"capget",
"capset",
"chdir",
"chmod",
"chown",
"chown32",
"clock_getres",
"clock_gettime",
"clock_nanosleep",
"close",
"connect",
"copy_file_range",
"creat",
"dup",
"dup2",
"dup3",
"epoll_create",
"epoll_create1",
"epoll_ctl",
"epoll_ctl_old",
"epoll_pwait",
"epoll_wait",
"epoll_wait_old",
"eventfd",
"eventfd2",
"execve",
"execveat",
"exit",
"exit_group",
"faccessat",
"fadvise64",
"fadvise64_64",
"fallocate",
"fanotify_mark",
"fchdir",
"fchmod",
"fchmodat",
"fchown",
"fchown32",
"fchownat",
"fcntl",
"fcntl64",
"fdatasync",
"fgetxattr",
"flistxattr",
"flock",
"fork",
"fremovexattr",
"fsetxattr",
"fstat",
"fstat64",
"fstatat64",
"fstatfs",
"fstatfs64",
"fsync",
"ftruncate",
"ftruncate64",
"futex",
"futimesat",
"getcpu",
"getcwd",
"getdents",
"getdents64",
"getegid",
"getegid32",
"geteuid",
"geteuid32",
"getgid",
"getgid32",
"getgroups",
"getgroups32",
"getitimer",
"getpeername",
"getpgid",
"getpgrp",
"getpid",
"getppid",
"getpriority",
"getrandom",
"getresgid",
"getresgid32",
"getresuid",
"getresuid32",
"getrlimit",
"get_robust_list",
"getrusage",
"getsid",
"getsockname",
"getsockopt",
"get_thread_area",
"gettid",
"gettimeofday",
"getuid",
"getuid32",
"getxattr",
"inotify_add_watch",
"inotify_init",
"inotify_init1",
"inotify_rm_watch",
"io_cancel",
"ioctl",
"io_destroy",
"io_getevents",
"ioprio_get",
"ioprio_set",
"io_setup",
"io_submit",
"ipc",
"kill",
"lchown",
"lchown32",
"lgetxattr",
"link",
"linkat",
"listen",
"listxattr",
"llistxattr",
"_llseek",
"lremovexattr",
"lseek",
"lsetxattr",
"lstat",
"lstat64",
"madvise",
"memfd_create",
"mincore",
"mkdir",
"mkdirat",
"mknod",
"mknodat",
"mlock",
"mlock2",
"mlockall",
"mmap",
"mmap2",
"mprotect",
"mq_getsetattr",
"mq_notify",
"mq_open",
"mq_timedreceive",
"mq_timedsend",
"mq_unlink",
"mremap",
"msgctl",
"msgget",
"msgrcv",
"msgsnd",
"msync",
"munlock",
"munlockall",
"munmap",
"nanosleep",
"newfstatat",
"_newselect",
"open",
"openat",
"pause",
"pipe",
"pipe2",
"poll",
"ppoll",
"prctl",
"pread64",
"preadv",
"prlimit64",
"pselect6",
"pwrite64",
"pwritev",
"read",
"readahead",
"readlink",
"readlinkat",
"readv",
"recv",
"recvfrom",
"recvmmsg",
"recvmsg",
"remap_file_pages",
"removexattr",
"rename",
"renameat",
"renameat2",
"restart_syscall",
"rmdir",
"rt_sigaction",
"rt_sigpending",
"rt_sigprocmask",
"rt_sigqueueinfo",
"rt_sigreturn",
"rt_sigsuspend",
"rt_sigtimedwait",
"rt_tgsigqueueinfo",
"sched_getaffinity",
"sched_getattr",
"sched_getparam",
"sched_get_priority_max",
"sched_get_priority_min",
"sched_getscheduler",
"sched_rr_get_interval",
"sched_setaffinity",
"sched_setattr",
"sched_setparam",
"sched_setscheduler",
"sched_yield",
"seccomp",
"select",
"semctl",
"semget",
"semop",
"semtimedop",
"send",
"sendfile",
"sendfile64",
"sendmmsg",
"sendmsg",
"sendto",
"setfsgid",
"setfsgid32",
"setfsuid",
"setfsuid32",
"setgid",
"setgid32",
"setgroups",
"setgroups32",
"setitimer",
"setpgid",
"setpriority",
"setregid",
"setregid32",
"setresgid",
"setresgid32",
"setresuid",
"setresuid32",
"setreuid",
"setreuid32",
"setrlimit",
"set_robust_list",
"setsid",
"setsockopt",
"set_thread_area",
"set_tid_address",
"setuid",
"setuid32",
"setxattr",
"shmat",
"shmctl",
"shmdt",
"shmget",
"shutdown",
"sigaltstack",
"signalfd",
"signalfd4",
"sigreturn",
"socket",
"socketcall",
"socketpair",
"splice",
"stat",
"stat64",
"statfs",
"statfs64",
"symlink",
"symlinkat",
"sync",
"sync_file_range",
"syncfs",
"sysinfo",
"syslog",
"tee",
"tgkill",
"time",
"timer_create",
"timer_delete",
"timerfd_create",
"timerfd_gettime",
"timerfd_settime",
"timer_getoverrun",
"timer_gettime",
"timer_settime",
"times",
"tkill",
"truncate",
"truncate64",
"ugetrlimit",
"umask",
"uname",
"unlink",
"unlinkat",
"utime",
"utimensat",
"utimes",
"vfork",
"vmsplice",
"wait4",
"waitid",
"waitpid",
"write",
"writev",
"mount",
"umount2",
"reboot",
"name_to_handle_at",
"unshare"
],
"action": "SCMP_ACT_ALLOW",
"args": [],
"comment": "",
"includes": {},
"excludes": {}
},
{
"names": [
"personality"
],
"action": "SCMP_ACT_ALLOW",
"args": [
{
"index": 0,
"value": 0,
"valueTwo": 0,
"op": "SCMP_CMP_EQ"
}
],
"comment": "",
"includes": {},
"excludes": {}
},
{
"names": [
"personality"
],
"action": "SCMP_ACT_ALLOW",
"args": [
{
"index": 0,
"value": 8,
"valueTwo": 0,
"op": "SCMP_CMP_EQ"
}
],
"comment": "",
"includes": {},
"excludes": {}
},
{
"names": [
"personality"
],
"action": "SCMP_ACT_ALLOW",
"args": [
{
"index": 0,
"value": 4294967295,
"valueTwo": 0,
"op": "SCMP_CMP_EQ"
}
],
"comment": "",
"includes": {},
"excludes": {}
},
{
"names": [
"breakpoint",
"cacheflush",
"set_tls"
],
"action": "SCMP_ACT_ALLOW",
"args": [],
"comment": "",
"includes": {
"arches": [
"arm",
"arm64"
]
},
"excludes": {}
},
{
"names": [
"arch_prctl"
],
"action": "SCMP_ACT_ALLOW",
"args": [],
"comment": "",
"includes": {
"arches": [
"amd64",
"x32"
]
},
"excludes": {}
},
{
"names": [
"modify_ldt"
],
"action": "SCMP_ACT_ALLOW",
"args": [],
"comment": "",
"includes": {
"arches": [
"amd64",
"x32",
"x86"
]
},
"excludes": {}
},
{
"names": [
"s390_pci_mmio_read",
"s390_pci_mmio_write",
"s390_runtime_instr"
],
"action": "SCMP_ACT_ALLOW",
"args": [],
"comment": "",
"includes": {
"arches": [
"s390",
"s390x"
]
},
"excludes": {}
},
{
"names": [
"open_by_handle_at"
],
"action": "SCMP_ACT_ALLOW",
"args": [],
"comment": "",
"includes": {
"caps": [
"CAP_DAC_READ_SEARCH"
]
},
"excludes": {}
},
{
"names": [
"bpf",
"clone",
"fanotify_init",
"lookup_dcookie",
"mount",
"name_to_handle_at",
"perf_event_open",
"setdomainname",
"sethostname",
"setns",
"umount",
"umount2",
"unshare"
],
"action": "SCMP_ACT_ALLOW",
"args": [],
"comment": "",
"includes": {
"caps": [
"CAP_SYS_ADMIN"
]
},
"excludes": {}
},
{
"names": [
"clone"
],
"action": "SCMP_ACT_ALLOW",
"args": [
{
"index": 0,
"value": 2080505856,
"valueTwo": 0,
"op": "SCMP_CMP_MASKED_EQ"
}
],
"comment": "",
"includes": {},
"excludes": {
"caps": [
"CAP_SYS_ADMIN"
],
"arches": [
"s390",
"s390x"
]
}
},
{
"names": [
"clone"
],
"action": "SCMP_ACT_ALLOW",
"args": [
{
"index": 1,
"value": 2080505856,
"valueTwo": 0,
"op": "SCMP_CMP_MASKED_EQ"
}
],
"comment": "s390 parameter ordering for clone is different",
"includes": {
"arches": [
"s390",
"s390x"
]
},
"excludes": {
"caps": [
"CAP_SYS_ADMIN"
]
}
},
{
"names": [
"reboot"
],
"action": "SCMP_ACT_ALLOW",
"args": [],
"comment": "",
"includes": {
"caps": [
"CAP_SYS_BOOT"
]
},
"excludes": {}
},
{
"names": [
"chroot"
],
"action": "SCMP_ACT_ALLOW",
"args": [],
"comment": "",
"includes": {
"caps": [
"CAP_SYS_CHROOT"
]
},
"excludes": {}
},
{
"names": [
"delete_module",
"init_module",
"finit_module",
"query_module"
],
"action": "SCMP_ACT_ALLOW",
"args": [],
"comment": "",
"includes": {
"caps": [
"CAP_SYS_MODULE"
]
},
"excludes": {}
},
{
"names": [
"acct"
],
"action": "SCMP_ACT_ALLOW",
"args": [],
"comment": "",
"includes": {
"caps": [
"CAP_SYS_PACCT"
]
},
"excludes": {}
},
{
"names": [
"kcmp",
"process_vm_readv",
"process_vm_writev",
"ptrace"
],
"action": "SCMP_ACT_ALLOW",
"args": [],
"comment": "",
"includes": {
"caps": [
"CAP_SYS_PTRACE"
]
},
"excludes": {}
},
{
"names": [
"iopl",
"ioperm"
],
"action": "SCMP_ACT_ALLOW",
"args": [],
"comment": "",
"includes": {
"caps": [
"CAP_SYS_RAWIO"
]
},
"excludes": {}
},
{
"names": [
"settimeofday",
"stime",
"adjtimex"
],
"action": "SCMP_ACT_ALLOW",
"args": [],
"comment": "",
"includes": {
"caps": [
"CAP_SYS_TIME"
]
},
"excludes": {}
},
{
"names": [
"vhangup"
],
"action": "SCMP_ACT_ALLOW",
"args": [],
"comment": "",
"includes": {
"caps": [
"CAP_SYS_TTY_CONFIG"
]
},
"excludes": {}
}
]
New user here too, doesn't build on my Docker for Mac.
Same error as benjamin-bergia, but now, I'll try directly on kube as it is where I want to use it :)
Thanks for the info!
pierreozoux
on 13 Oct 2019
Error during unshare(CLONE_NEWUSER): Operation not permitted
ERRO[0000] error parsing PID "": strconv.Atoi: parsing "": invalid syntax
ERRO[0000] (unable to determine exit status)
Hit this issue recently as well, trying to use docker from the Github Actions (Ubuntu) environment.
With Github Actions execution environment (Ubuntu), it's _possible_ to specify your own docker argument but complicates / is unidiomatic. However, I believe it _is_ possible to install a new system-wide seccomp.json as a workaround.
Could that be a workaround for this in Github Actions or are other docker security arguments needed?
cevich
on 18 Oct 2019
Update: I downloaded podman's seccomp.json then stuck this into /etc/docker/daemon.json:
{"seccomp-profile": "/root/seccomp.json"}, and restarted the docker daemon. I get further now, using a Fedora 30 container image w/ buildah installed:
[root@1011ba0fd858 ~]# buildah --storage-driver=vfs from fedora-minimal:latest
Getting image source signatures
Copying blob fbeae81c958c done
Copying config 53dcc6ef21 done
Writing manifest to image destination
Storing signatures
ERRO Error while applying layer: ApplyLayer exit status 1 stdout: stderr: permission denied
^C
[root@1011ba0fd858 ~]#
It appeared to "hang" though responded to me pressing enter. So for running buildah in docker containers...more is needed :thinking:
cevich
on 18 Oct 2019
Final update: I got it working, but it ain't pretty. Docker's handling of it's AppArmor profile is absolutely horrendous: Dynamically generated, verified on every execution, and no possibility to override or bypass it just for docker. So I brought out the big gun and disabled the entire darned thing (systemctl stop apparmor && apt-get remove apparmor). Now buildah works just fine and dandy as a GitHub Action under Ubuntu (using podman's seccomp.json as above).
Not sure we want to document this as a recommended solution for docker. It may be fine for public CI/CD type systems, but certainly NIMBY situation otherwise :confounded:
cevich
on 18 Oct 2019
I am fine with that solution.
rhatdan
on 18 Oct 2019
@TomSweeneyRedHat have any suggestions on what to do with what I found WRT docker + ubuntu? Do we have any existing places I could toss a step-by-step into?
cevich
on 21 Oct 2019
Going through the list of old issues. @bachp is this still something you are interested in? @TomSweeneyRedHat @ipbabble Is this still something we want?
rhatdan
on 4 Aug 2020
Want yes.
TomSweeneyRedHat
on 4 Aug 2020
@rhatdan Yes I'm still interested. The main focus is still how to run buildah within an unprivileged docker container (if possible).
bachp
on 4 Aug 2020
@bachp Is CRI-O or Podman a possibility.
Buildah can be run within the Docker daemon, but the container requires to at least have SETUID/SETGID perms and a modified SECCOMP.json file. Podman/CRI-O run with the corrected seccomp.json file.
rhatdan
on 6 Aug 2020
@bachp Sadly in this specific case Podman and CRI-O is not an option.
But the additional capabilities and the seccomp.json modifcations are exactly the things I think should be documented.
bachp
on 6 Aug 2020
docker run --security-opt seccomp:unconfined ...
Should get the job done.
rhatdan
on 7 Aug 2020
@bachp were are we on this one? Is the documentation good enough yet?
rhatdan
on 8 Oct 2020
@rhatdan Could you provide a link to the documentation you are refering to? So I could verify.
bachp
on 8 Oct 2020
@bachp I am talking about the tuturial and readme on github.
rhatdan
on 6 Nov 2020
Related issues
tensor5
·
5Comments
sub-mod
·
4Comments
zhouhao3
·
9Comments
sourabhsharma487
·
11Comments
azatsarynnyy
·
3Comments
Most helpful comment
I'd like to add that it is really confusing whether
buildahis without any sort of root access or a "privileged" container. I can't seem to find a place that answers this concisely and completely and builds my intuition. Issues like #1335 kind of mirror my lack of understanding/frustration -- doesbuildahbuild containers without root permissions or not (assumingseccompis not an issue)?From what I understand, the key to making
buildahwork in a non-root environments is the use of:I've enabled user namespaces unprivileged user names spaces via
sysctl:FUSE libraries are installed on my distro -- yet when I attempt to run buildah from inside an unprivileged
fedoraorbuildah/buildahcontainer, I get this error:As a new user it's kind of unclear to me what I'm doing wrong here, does the "rootless" building that
buildahis doing refer to after you've started a container as root on the host system already? Am I missing options? It seems like I need to be running with the alternate isolation mode (chroot) and possibly forcingbuildahto use a FUSE driver to get a truly "rootless" build?If I run
docker runwith--privilegedit will work spectacularly which is great, but I am looking intobuildahbecause it seems to offer a way to not have to use a privileged container to start with.[EDIT] - I want to add that looking through github issues, blog posts, and release notes (like 1.5 for example), It's not 100% clear what the difference between "rootless mode" and any other mode.
[EDIT2] - A related issue I also came across suggests that maybe I should be using
BUILDAH_ISOLATIONset torootless? I double checked and I am using a version ofbuildahthat is new enough to have the fix merged --1.8.2IIRC yet that didn't work for me either.