[lczyk]

• Have you signed the CLA?

---

did some formal verification (fizzbee, my specs are here and here) of the cut path and found 7 minor bugs:

• fix: prefer ignores x-arch paths #330
• fix: validation miss for mutable: true, until: mutate #331
• fix: implicit parents hiding explicit paths #332
• fix: manifest attribution of until: mutate #333
• fix: hard links against content from another package #334
• fix: hard links whose target is not in the manifest #335
• fix: listed mode of copied paths #336 (this PR)

cut the following slice:

# slices/test-package.yaml
package: test-package
slices:
  myslice:
    contents:
      /dir/file: {mode: 0600}

$ chisel cut --release ./ --arch amd64 --root $rootfs test-package_myslice
Extracting files from package "test-package"...
$ stat -c '%a' $rootfs/dir/file
644

the listed mode is parsed and validated but never reaches the extraction, so copied files and directories keep the mode from the deb. text, make and symlink entries do honour it. rabbitmq-server lists two such entries on every chisel-releases branch since 22.04. ( <- @zhijie-yang fyi, since you're the rabbit expert )

repro using chisel-proxy:

$ alias chisel-proxy='go run github.com/lczyk/chisel-proxy/cmd/chisel-proxy@v0.3.0'
$ mkdir -p test-package/dir
$ echo data > test-package/dir/file
$ chisel-proxy cut --arch amd64 ./test-package ./test-package.yaml \
    -- --root ./rootfs test-package_myslice
Extracting files from package "test-package"...
$ stat -c '%a' ./rootfs/dir/file
644

with the fix both print 600.

fix

the mode is passed along in the extraction request. a hard link with a listed mode shares its target's inode when the modes agree and is otherwise extracted as a file of its own with that mode; pending links to the same target are grouped by mode the same way. a mode listed for one destination of a source no longer leaks into another destination of the same source. one consequence: a mode on a path that a glob of the same package also matches now fails the cut with requested twice with diverging mode (the extraction's existing contract, pinned by its "Entries for same destination must have the same mode" test); pinned here in a slicer case rather than relaxed. no slice on any ubuntu-* branch has that overlap.

[Copilot]

🟡 Changes recommended

Hard-link modes and per-destination mode handling still have unresolved issues.

2 open findings

• Reset shared tar header mode between target extractions · New
• Apply requested mode when extracting hard links · New

What changed in this PR

Fixes listed modes for copied files and directories during extraction.

Changes:

• Propagates listed modes to tarball extraction.
• Adds regression tests for mode application and conflicting glob matches.

File	Summary
internal/​slicer/​slicer.go	Passes listed modes to tarball extraction.
internal/​slicer/​slicer_test.go	Adds mode and conflict regression tests.

🧠 Review effort: Lite

---

💡 Add a code-review agent skill or configure MCP servers for context-aware, tailored reviews. Learn more in the docs.

[Copilot]

🟡 Changes recommended

A mode can still leak from an earlier hard-link destination to a later destination without an explicit mode.

1 open finding

• Pending link mode leaks to later destinations · New

2 resolved since last review

• Apply requested mode when extracting hard links
• Reset shared tar header mode between target extractions

🧠 Review effort: Lite

[upils]

@lczyk as stated in the docs, this mode can only be used on path Chisel creates, so in combination with copy, make, text or symlink. It is not intended to be used to change the mode of a path actually coming from the package. I think the real bug here is that Chisel does not check that. So I would lean toward being more strict for now when validating the YAMLs to make sure mode is always used with the other keys.

[lczyk]

@upils hmmm.. if "permission bits for any path chisel creates ... can only be used with copy, make and text" then chisel should enforce that. having said that, i've checked chisel-releases and atm there is a use for this: rabbitmq-server has /var/lib/rabbitmq/mnesia/: { mode: 0750 } on 22.04, 24.04, 26.04 and 26.10. the deb ships that dir as 0755 root:root and the postinst does chmod 750 + chown -R rabbitmq:rabbitmq, so the slice copies half of the postinst.

@zhijie-yang looping you in since its about 🐰

[upils]

Isn't the deb doing something wrong here? What it could do instead is:

• ship the dir with the proper mode. In that case nothing to do on our side (I am putting aside the ownership issue on purpose)
• Also use make: true but this might slightly misleading if the package keep shipping the dir.

This may be a bit late to change these packages though... But I think this is an abuse of a bug we missed. I think we should push for packages to behave as best as they can and only tweak as few things as we can in chisel-releases. I know this is not possible in all cases and mutation scripts are here to bridge the gap, but the feature set is limited on purpose.