Support xattrs in the build sandbox #838

Open
opened 2025-05-22 23:21:28 +00:00 by jade · 2 comments
Owner

I found out today that we block xattrs usage with seccomp on Linux: https://git.lix.systems/lix-project/lix/src/5ca168f6f2dfda3aa047386de6d8733fcddff1bd/lix/libstore/platform/linux.cc#L701-L706

This is not ideal and we probably want to allow it especially if we do #298, since it will prevent running our own test suite inside the nix sandbox.

The reason that xattrs are blocked in the first place is that they aren't representable in NARs so you could have local builds with different results than substitutions. There's a couple of issues with the way this is implemented:

  • It blocks xattr usage in the build directory unnecessarily by using too big a hammer to try to block them landing in derivation outputs. It's not easy to block xattrs just on build directories, but:
    • We could block setting xattrs via something like bindfs's option to make them readonly and use that on input-addressed derivations' output paths https://bindfs.org/docs/bindfs.1.html
    • We could scan outputs for xattrs and either fail the build or delete them; this is likely to have some performance cost, but it's unclear if scanning this is that expensive (and we already do have to do a ref-scanning pass anyway!).
  • It turns out that for lol lmao reasons setting xattrs on build output is not actually blocked on macOS at all, today. It might well just be Fine and Ignorable even if Not Ideal!
$ nix-build --expr 'with import <nixpkgs> {}; runCommand "meow" {} "touch $out; /usr/bin/xattr -w meow kitty $out"'
this derivation will be built:
  /nix/store/pwinv2bgjb5zdv0jx58l08chfvp3hw7y-meow.drv
building '/nix/store/pwinv2bgjb5zdv0jx58l08chfvp3hw7y-meow.drv'...
/nix/store/gh1m65y27b93afxsrfqw9d7dkxja060v-meow

$ xattr -r /nix/store/gh1m65y27b93afxsrfqw9d7dkxja060v-meow
/nix/store/gh1m65y27b93afxsrfqw9d7dkxja060v-meow: meow

So like, you know...

I found out today that we block xattrs usage with seccomp on Linux: https://git.lix.systems/lix-project/lix/src/5ca168f6f2dfda3aa047386de6d8733fcddff1bd/lix/libstore/platform/linux.cc#L701-L706 This is not ideal and we probably want to allow it especially if we do https://git.lix.systems/lix-project/lix/issues/298, since it will prevent running our own test suite inside the nix sandbox. The reason that xattrs are blocked in the first place is that they aren't representable in NARs so you could have local builds with different results than substitutions. There's a couple of issues with the way this is implemented: - It blocks xattr usage in the build directory unnecessarily by using too big a hammer to try to block them landing in derivation outputs. It's not *easy* to block xattrs just on build directories, but: - We could block setting xattrs via something like bindfs's option to make them readonly and use that on input-addressed derivations' output paths https://bindfs.org/docs/bindfs.1.html - We could scan outputs for xattrs and either fail the build or delete them; this is likely to have some performance cost, but it's unclear if scanning this is that expensive (and we already do have to do a ref-scanning pass anyway!). - It turns out that for lol lmao reasons *setting xattrs on build output* is not actually blocked on macOS at all, today. It might well just be Fine and Ignorable even if Not Ideal! ``` $ nix-build --expr 'with import <nixpkgs> {}; runCommand "meow" {} "touch $out; /usr/bin/xattr -w meow kitty $out"' this derivation will be built: /nix/store/pwinv2bgjb5zdv0jx58l08chfvp3hw7y-meow.drv building '/nix/store/pwinv2bgjb5zdv0jx58l08chfvp3hw7y-meow.drv'... /nix/store/gh1m65y27b93afxsrfqw9d7dkxja060v-meow $ xattr -r /nix/store/gh1m65y27b93afxsrfqw9d7dkxja060v-meow /nix/store/gh1m65y27b93afxsrfqw9d7dkxja060v-meow: meow ``` So like, you know...
raito added this to the 2.95 milestone 2026-01-02 19:10:01 +00:00
Owner

the seccomp filter that disables setxattr and friends was introduced in may 2017. it's been An While™ since then, the "some filesystems don't support them" justification is increasingly untrue, and on linux all places (that we checked) that add anything to the store include a canonicalization step that just drops all xattrs in the input anyway. this never having happened on macos and nothing having broken in the meantime is reasonable justification to assume that nothing actually uses them, so enabling them should be mostly fine.

a while ago we opened #1008 for clearing xattrs on non-linux specifically, that should still be done.

we'll have to look into that in the near future anyway, so we'll probably end up just allowing xattrs

the seccomp filter that disables setxattr and friends was introduced in may 2017. it's been An While™ since then, the "some filesystems don't support them" justification is increasingly untrue, and on linux all places (*that we checked*) that add anything to the store include a canonicalization step that just *drops* all xattrs in the input anyway. this never having happened on macos and nothing having broken in the meantime is reasonable justification to assume that nothing actually uses them, so enabling them should be mostly fine. a while ago we opened #1008 for clearing xattrs on non-linux specifically, that should still be done. we'll have to look into that in the near future anyway, so we'll probably end up just allowing xattrs
Member

This issue was mentioned on Gerrit on the following CLs:

  • commit message in cl/4856 ("libstore/platform/linux: allow xattrs in the sandbox")
<!-- GERRIT_LINKBOT: {"cls": [{"backlink": "https://gerrit.lix.systems/c/lix/+/4856", "number": 4856, "kind": "commit message"}], "cl_meta": {"4856": {"change_title": "libstore/platform/linux: allow xattrs in the sandbox"}}} --> This issue was mentioned on Gerrit on the following CLs: * commit message in [cl/4856](https://gerrit.lix.systems/c/lix/+/4856) ("libstore/platform/linux: allow xattrs in the sandbox")
Sign in to join this conversation.
No milestone
No project
No assignees
3 participants
Notifications
Due date
The due date is invalid or out of range. Please use the format "yyyy-mm-dd".

No due date set.

Dependencies

No dependencies set.

Reference
lix-project/lix#838
No description provided.