skip read /proc/filesystems if process_label is null

[ningmingxiao]

when compare to crun runc will open "/proc/filesystems" even process_label is null
when I try to make runc exec faster
#3181

[lifubang]

Good news, thanks. Did you have a benchmark to test how faster than before? For example, you can run 1000 times ’runc exec’.

[ningmingxiao]

Good news, thanks. Did you have a benchmark to test how faster than before? For example, you can run 1000 times ’runc exec’.
runc 1.1.12
old

[root@localhost runc]#  time for ((i=0; i<1000;i++)); do runc exec nmx002 true; done
real    0m46.434s
user    0m9.970s
sys     0m19.874s

after this pr

[root@localhost runc]#  time for ((i=0; i<1000;i++)); do runc exec nmx001 true; done

real    0m44.850s
user    0m9.953s
sys     0m19.343s

will improve little.

[thaJeztah]

Do we know what the intent was for these empty selinux.SetKeyLabel("") ? See my comment on opencontainers/selinux#214 (comment)

[lifubang]

I think it's used to clear the label for the next keyring created by the current process once we got an error when we start/exec the container. Because this label can't be inherited by sub-process, so the initial value should be "", so we can set it to an empty string directly to clear it.

[ningmingxiao]

can we use unix.KeyctlString() set keylabel ? @lifubang

[lifubang]

can we use unix.KeyctlString() set keylabel ?

I think no.

[kolyshkin]

Do we know what the intent was for these empty selinux.SetKeyLabel("") ? See my comment on opencontainers/selinux#214 (comment)

Some are added by commit cd96170, and some are by aa3fee6, which provides an explanation:

should also call SetProcessLabel("") after the container starts
to go back to the default SELinux behaviour.

Given the fact that Init() never returns unless there's an error (because it ends with exec), those defers are only called in case of an error.

[kolyshkin]

I think the performance overhead is negligible (as the /proc/filesystems is only read once per binary invocation).

As to whether we can skip SetKeyLabel and SetExecLabel calls (and defers) if config.ProcessLabel is empty, I assume this is a valid approach, but perhaps @rhatdan can shed some light.

[kolyshkin]

I re-reviewed this and the approach seems totally correct to me.

[lifubang]

Another think, do you think this is intend to clear the key label of the process if l.config.ProcessLabel == ""?

[kolyshkin]

That was my worry as well. As far as I understand, by default the the context of the creating process is used, and when you write an empty string to /proc/self/attr/keycreate it means the same thing ("use the current context").

So, to my best understanding, writing an empty string and not writing anything is the same thing here.

Maybe @rhatdan will correct me here.

[kolyshkin]

@ningmingxiao please use "rebase" rather than "merge", and remove the merge commit.

[ningmingxiao]

@ningmingxiao please use "rebase" rather than "merge", and remove the merge commit.

done

[kolyshkin]

@opencontainers/runc-maintainers PTAL

[rata]

LGTM. If this ends up causing a regression, it would be great to add tests

[rata]

@lifubang do you want to have a last review or shall I merge?

[lifubang]

@lifubang do you want to have a last review or shall I merge?

What do you think about this one?
#4354 (comment)

[rata]

@lifubang Is @kolyshkin answer not enough. Wanna verify that or what do you propose?

[lifubang]

@lifubang Is @kolyshkin answer not enough. Wanna verify that or what do you propose?

As @kolyshkin said: "So, to my best understanding, writing an empty string and not writing anything is the same thing here."
I has verified it, for this PR, I think it's correct, writing an empty string means using the default selinux security context.
But there may be a bug for runc exec --process-label="", we have no opportunity to use the default process label to exec into a container now.