`linux`: Support setting execution domain via linux `personality`.

[flouthoc]

Hi Team,

Following PR allows users to configure execution domain via syscall.SYS_PERSONALITY. Valid inputs supported via spec are limited to LINUX and LINUX32.

References: https://man7.org/linux/man-pages/man2/personality.2.html https://raw.githubusercontent.com/torvalds/linux/master/include/uapi/linux/personality.h

[kolyshkin]

@flouthoc can you describe the use case? I thought it's for starting i386 binaries but they work as is.

I think internally it's better to represent the personality value as a number rather than a string.

[kolyshkin]

This should shed some light: https://github.com/opencontainers/runtime-spec/commit/5cc25d0a579261273809ff9db503a49af4771aaa

crun support: https://github.com/containers/crun/commit/afc183b85518a14828d264fb983392f1a65009e0

[flouthoc]

@kolyshkin the commit you shared describes the edge-case but I also think that build for any i386 or 32-bit binary will fail if current kernel is on 64-bit also certain 32-bit userspace apps expect uname -m to report i686. Following cases could be resolved by setting LINUX32 execution domain.

Also added as comment here https://github.com/opencontainers/runc/pull/3126/files#diff-96def2e006cb3518f1aaf9a595a80648521905e352e625550bff15aaa0019fa0R404

I think internally it's better to represent the personality value as a number rather than a string.

For this personalty is defined as number const internally in runc but accepted as string via spec since that is how it is defined in upstream runtime-spec this would required change in upstream. Please correct me if i am wrong.

const (
	PER_LINUX   = 0x0000
	PER_LINUX32 = 0x0008
)

[kolyshkin]

It's kind of weird that

1. this is still not implemented
2. this is not implemented by checking the architecture of container init binary (so, say, if we're running i386 binary, runc calls personality(PER_LINUX32) for us.

But I guess it is what it is.

[kolyshkin]

For this personalty is defined as number const internally in runc but accepted as string via spec since that is how it is defined in upstream runtime-spec this would required change in upstream. Please correct me if i am wrong.

I didn't mean to change the runtime spec. What I meant is we're converting the spec into our internal presentation anyway (in libcontainer/specconv), and this is where, I think, we should do a string -> number translation.

[flouthoc]

@kolyshkin Applied requested changes could you please review again.

[flouthoc]

@AkihiroSuda @kolyshkin We would also need downstream pr on managers / shims to support this. https://github.com/containers/podman/pull/11141

[flouthoc]

@kolyshkin anything else which needs to be done from my side.

[flouthoc]

@kolyshkin Could you please take a look again ? resolved the feedback comments and added integration tests. Also changed the approach a little bit.

• Instead of invoking syscall from runner we are now invoking it from linuxcontainer.Start , since integration tests are invoking Start directly instead of using CLI also new approach seems much better to me since personality is limited only to linux containers.

[flouthoc]

@kolyshkin Squeezed personality tests with exec integration tests, let me know if separate file needs to created.

[flouthoc]

@kolyshkin were you able to take a look at this, is there anything else with needs to be done from my side

[flouthoc]

@kolyshkin resolved all the feedback points, could you please take a look again.

[AkihiroSuda]

@flouthoc Could you update the PR?

[kolyshkin]

@flouthoc do you still want to work on this one? If yes, can you please rebase?

[Zheaoli]

@kolyshkin @AkihiroSuda @cyphar Hello guys, this PR seems been deprecated for a while. may I take handle of it and carry it?

[AkihiroSuda]

@kolyshkin @AkihiroSuda @cyphar Hello guys, this PR seems been deprecated for a while. may I take handle of it and carry it?

Yes, please

[flouthoc]

Closing this PR in favor of above discussion. @Zheaoli Could you please open a new PR for this, feel free to copy whatever code is needed as it is or change parts as per needs i'm not sure if its code in this PR is updated as per recent runc version but hope it works.

[Zheaoli]

Closing this PR in favor of above discussion. @Zheaoli Could you please open a new PR for this, feel free to copy whatever code is needed as it is or change parts as per needs i'm not sure if its code in this PR is updated as per recent runc version but hope it works.

Of course, thanks for your work!

[AkihiroSuda]

@Zheaoli Do you plan to open a new PR?

[Zheaoli]

@Zheaoli Do you plan to open a new PR?

Yes I will open a new PR this weekend