[[["易于理解","easyToUnderstand","thumb-up"],["解决了我的问题","solvedMyProblem","thumb-up"],["其他","otherUp","thumb-up"]],[["没有我需要的信息","missingTheInformationINeed","thumb-down"],["太复杂/步骤太多","tooComplicatedTooManySteps","thumb-down"],["内容需要更新","outOfDate","thumb-down"],["翻译问题","translationIssue","thumb-down"],["示例/代码问题","samplesCodeIssue","thumb-down"],["其他","otherDown","thumb-down"]],["最后更新时间 (UTC)：2025-07-26。"],[[["\u003cp\u003e\u003ccode\u003eRepositoryContext\u003c/code\u003e enables repositories to make asynchronous calls to the Cloud Search SDK, primarily for handling document modification detection.\u003c/p\u003e\n"],["\u003cp\u003eIt's created by traversal connectors (\u003ccode\u003eFullTraversalConnector\u003c/code\u003e, \u003ccode\u003eListingConnector\u003c/code\u003e) and passed to the repository during initialization.\u003c/p\u003e\n"],["\u003cp\u003eRepositories use the \u003ccode\u003epostApiOperationAsync\u003c/code\u003e method within \u003ccode\u003eRepositoryContext\u003c/code\u003e to inform Cloud Search of document changes, enabling near real-time updates.\u003c/p\u003e\n"],["\u003cp\u003eThe \u003ccode\u003egetDefaultAclMode\u003c/code\u003e method provides access to the default access control list mode configured for the connector.\u003c/p\u003e\n"]]],[],null,["Can I use threads?\n\nYes, threads are supported in Sandbox2.\n\nAll threads must be sandboxed\n\nBecause of the way Linux works, the seccomp-bpf policy is applied to the current\nthread only: this means the policy is not applied to other existing threads, but\nfuture threads will inherit the policy:\n\n- If you are using Sandbox2 in the [first\n mode](/code-sandboxing/sandbox2/getting-started#method_1_stand-alone_%E2%80%93_execute_a_binary_with_sandboxing_already_enabled) where sandboxing is enabled before `execve()`, all threads will inherit the policy, and there is no problem. This is the preferred mode of sandboxing.\n- If you are using the [second\n mode](/code-sandboxing/sandbox2/getting-started#method_2_sandbox2_forkserver_%E2%80%93_tell_the_executor_when_to_be_sandboxed) where the executor has `set_enable_sandbox_before_exec(false)` and the Sandboxee tells the executor when it wants to be sandboxed with `SandboxMeHere()`, ensure the filter is applied to all threads. Otherwise, there is a risk of a sandbox escape: malicious code could migrate from a sandboxed thread to an unsandboxed thread.\n\n| **Note:** The Linux kernel introduced the TSYNC flag in version 3.17, which allows applying a policy to all threads. Before this flag, it was only possible to apply the policy on a thread-by-thread basis. If Sandbox2 detects that it is running on a kernel without TSYNC-support and you call `SandboxMeHere()` from a multi-threaded program, Sandbox2 will abort, since this would compromise the safety of the sandbox.\n\nHow should I compile my Sandboxee?\n\nIn comparison to a statically linked executable, compiling the sandboxee to a\ndynamically linked executable will result in a significant increase of syscalls\n(e.g. `open`/`openat`, `mmap`, etc.) that need to be allowlisted. All of these\nadditional syscalls are required due to the dynamic linker invocation at runtime\nto load the shared libraries.\n\nHowever, looking at statically linked sandboxees: While fewer syscalls need to\nbe allowlisted, there are also security implications; the ASLR heap entropy is\nreduced (from 30 bits to 8 bits), which makes exploits easier.\n\nThis is a dilemma which can essentially be reduced to:\n\n- **Dynamic**: good heap ASLR, potentially harder to get initial code execution but at the cost of a less effective sandbox policy, potentially easier to break out of.\n- **Static**: bad heap ASLR, potentially easier to get initial code execution but a more effective sandbox policy, potentially harder to break out of.\n\nHistorically, statically linked binaries did not support position independent\ncode (`pie`). In addition, Bazel added `pie` by default. In order to be able to\ndefine a tight syscall filter, you had to overwrite Bazel's default value.\n\nCompilers have improved over the years and now support a `static-pie` option.\nWith this option a compiler is instructed to generate position-independent code,\nbut compared to `pie` this now also includes all the statically linked\nlibraries. From a security standpoint, `static-pie` still reduces the ASLR\nentropy (from 30 bits to 14 bits), but this is an improvement over the previous\nsituation without `pie`.\n\nAs Bazel adds `pie` by default and static is incompatible with it, consider\nusing the linker options flag to pass the `-static-pie` linker flag to the\n[cc_binary](https://docs.bazel.build/versions/master/be/c-cpp.html#cc_binary)\nrule and overwrite the default: \n\n linkstatic = 1,\n linkopts=[\"-static-pie\"],\n\nFor an example of these options, look at the\n[static](/code-sandboxing/sandbox2/examples#static) example\n[BUILD](https://github.com/google/sandboxed-api/blob/main/sandboxed_api/sandbox2/examples/static/BUILD):\nstatic_bin.cc is linked statically with `static-pie`, which makes it possible to\nhave a very tight syscall policy. This also works nicely for sandboxing\nthird-party binaries.\n\nCan I sandbox 32-bit x86 binaries?\n\nSandbox2 can only sandbox the same architecture as it was compiled with.\n\nIn addition, support for 32-bit x86 has been removed from Sandbox2. If you try\nto use a 64-bit x86 executor to sandbox a 32-bit x86 binary, or a 64-bit x86\nbinary making 32-bit syscalls (via int 0x80), both will generate a sandbox\nviolation that can be identified by the architecture label \\[X86-32\\].\n\nThe reason behind this behavior is that syscall numbers differ between\narchitectures and since the syscall policy is written in the architecture of the\nexecutor, it would be dangerous to allow a different architecture for the\nSandboxee. Indeed, this could lead to allowing a seemingly harmless syscall that\nin fact means another more harmful syscall could open up the sandbox to an\nescape.\n\nAre there any limits on the number of sandboxes an executor process can request?\n\nFor each Sandboxee instance (new process spawned from the forkserver), a new\nthread is created -- that's where the limitation lies.\n\nCan an Executor request the creation of more than one Sandbox?\n\nNo. There is a 1:1 relation -- an Executor instance stores the PID of the\nSandboxee, manages the Comms instance to the Sandbox instance, etc.\n\nWhy do I get \"Function not implemented\" inside forkserver.cc?\n\nSandbox2 only supports running on reasonably new kernels. Our current cut-off is\nthe 3.19 kernel, though that might change in the future. The reason for this is\nthat we are using relatively new kernel features including user namespaces and\nseccomp with the TSYNC flag.\n\nIf you are running on prod, this should not be in issue, since almost the entire\nfleet is running a new enough kernel. If you have any issues with this, please\ncontact us.\n\nIf you are running on Debian or Ubuntu, updating your kernel is as easy as\nrunning: \n\n sudo apt-get install linux-image-\u003cRECENT_VERSION\u003e"]]
