LGTM. Presumably we'll add all of the other hacks we need to get unprivileged containers here eventually?

I remember there are two other hacks,

1. remove "gid=5" in devpts mount options
2. remove "ro" in cgroup mount options

Now I don't need these two hacks and can run unprivileged container with config.json created by runc spec --userns.
I guess 2 is fixed by #763 , not sure why 1 is also not needed.

Wasn't the first only required when gid=5 wasn't mapped? It is in this patch, so guess that's why it's fine.

@codido gid=5 not being mapped wouldn't cause an issue AFAICS since if you don't have a mapping for that group it will still work (it'll just be using gid=5 on the host). And that's fine because we always mount everything inside the user namespace.

@cyphar unmapped uids/gids can't really be used in userns - I don't think you can setuid/setgid to an unmapped uid/gid.
If you change the mapping size to 5 (that is, 0-4 are mapped), you'll get something like this:

rootfs_linux.go:53: mounting "/dev/pts" to rootfs "/fs/rootfs" caused "invalid argument"

@codido Yes, sorry. My mistake, I forgot how unmapped ids work. Presumably we can generate the gid= argument -- but I'm curious as to why we use gid=5 (I just did some spelunking and have yet to figure out the reason).

@cyphar Guess that's just because the tty group is usually 5, at least on Fedora:

$ cat /etc/group
root:x:0:
bin:x:1:
daemon:x:2:
sys:x:3:
adm:x:4:
tty:x:5:

Hmmm. That means we can't really generate the argument. But if the tty group isn't mapped then we can just remove the gid=5 argument. But this is all about what default we should show in --userns.

@hqhq Do you think we should show a single-user unprivileged container with --userns or just a generic userns container? My thinking is that we could use this to be able to generate specs for completely unprivileged containers (a-la starting runc as a non-root user) in the future, once we've figured out what needs to be fixed.

Also, not sure if we want to add more options to runc spec. ocitools generate provides all the knobs while runc spec is more of a convenience. Might as well use that as it will work with any OCI compatible runtime.

+1 to having this in ocitools

Yeah, the intention for doing this is a lot of people asked me: hey, I have a config created by runc spec, how can I change it to run an unprivileged container.

If ocitools is capable for this, we don't need to expand runc spec anymore, but I think we should link this information from runc spec because not every runc user knows about ocitools, I'll close and file another PR, thanks.