Let sandbox supports custom user information settings

[yuanxingyang]

This patch is used to address the issue of needing to use a specific user ID during the compilation phase to connect to the server and validate the compiler license legality, e.g. QNX project qcc compiler need to check license via online server

[yuanxingyang]

The sandbox recipes will be like the following:

provideSandbox: paths: [ "/bin", "/usr/bin", "/sbin","usr/include"] mount: - [ "\\$HOME/.ssh", "\\$HOME/.ssh"] - [ "\\$HOME/.qnx", "\\$HOME/.qnx",[rw]] - [ "\\$HOME/.flexlmrc", "\\$HOME/.flexlmrc"] - [ "\\$HOME/qnx", "\\$HOME/qnx"] user: uid: "\\$UID" gid: "\\$UID"

[jkloetzke]

Thanks for the PR. Interesting that the license check is somehow influenced by the user/group id. Anyway, I think we shall support this.

I don't think we need a fully generic solution here, do we? Currently I see three sensible behaviours:

• Run as user "nobody" in the sandbox. This is currently the default.
• Run with the same user/group-Id. This seems to be you use case.
• Run as fake root in the sandbox. Already supported by namespace-sandbox but not exposed in Bob.

I would propose a new sandbox property that allows just the three cases above:

provideSandbox:
    user: "nobody" / "current" / "root"

Would you mind to update the PR in this direction? A couple of additional thoughts:

• It should be possible to adjust the behaviour in default.yaml too (sandbox key)
• The changes to the namespace-sandbox should be separate commits
• Some words in the documentation describing the new option should be added too
• Ideally some smoke test would be nice (maybe extend test/black-box/sandbox/... a bit?)

[yuanxingyang]

I don't mind and I'm very happy if you can make direct modifications on this PR.

I have a few ideas, see if you can adopt them：

1. Use '\$USER' instead of 'current', this way it's more intuitive and easier to understand provideSandbox: user: "nobody" / "\$USER" / "root"

2. When obtaining information about the current user, avoid accessing the /etc/passwd file. In some organizations, accounts are managed through the Active Directory mechanism, so there is no user information in the /etc/passwd file

[jkloetzke]

Please have a look at the current state of the PR. Let me know if it fits your needs...

[yuanxingyang]

Please have a look at the current state of the PR. Let me know if it fits your needs...

This PR perfectly implements my requirements, and I have validated it locally without any issues.

[jkloetzke]

Perfect. Thanks!