Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

jigdo relabeling ineffective for docker/container-selinux #1172

Closed
cgwalters opened this issue Jan 2, 2018 · 0 comments
Closed

jigdo relabeling ineffective for docker/container-selinux #1172

cgwalters opened this issue Jan 2, 2018 · 0 comments
Labels

Comments

@cgwalters
Copy link
Member

I thought I had this working before but perhaps not. Anyways I was doing some analysis on the current 90MB FAHC jigdoRPM:

find tmp-jigdo-out/x86_64/usr/lib/ostree-jigdo/fedora-atomic-host/05new/ -type f -size +1M | sed -e 's,^tmp-jigdo-out/x86_64/usr/lib/ostree-jigdo/fedora-atomic-host/05new/,,' |grep '/' | sed -e s,/,, | sort -u |  while read checksum; do echo -n ${checksum}':' && ~user/src/github/ostreedev/ostree-releng-scripts/find-object-filenames --repo=repo-build -o ${checksum} -e fedora/27/x86_64/atomic-host; done
23761aa2e72668eff9542edc9c089a29e00c7cdab3ebe8fdbb4331be46fbe43f:fedora/27/x86_64/atomic-host => cadb1ae8cc017ccab7566af022be32f5f55f5e781bb02a4363303e3a4631e28f : /usr/bin/runc
250eece212fe71cedf93042cb2ab3468cab99cfdd1b3b5b472c50d4946663290:fedora/27/x86_64/atomic-host => cadb1ae8cc017ccab7566af022be32f5f55f5e781bb02a4363303e3a4631e28f : /usr/bin/dockerd-current
376eed407110eac848f24698e8fd50c53ff4549f52d291dfad8aa9f19abc9828:fedora/27/x86_64/atomic-host => cadb1ae8cc017ccab7566af022be32f5f55f5e781bb02a4363303e3a4631e28f : /boot/efi/EFI/fedora/shimx64-fedora.efi
4bfd2496187505fa91becc863881d1f44d5e18e54b26c5c3c449353a42502a45:fedora/27/x86_64/atomic-host => cadb1ae8cc017ccab7566af022be32f5f55f5e781bb02a4363303e3a4631e28f : /usr/bin/docker-current
551ac9f0c3d46d3f73ea27eff98de2e5f1edb8e3f269df5c59e43a466e9a4db2:fedora/27/x86_64/atomic-host => cadb1ae8cc017ccab7566af022be32f5f55f5e781bb02a4363303e3a4631e28f : /usr/libexec/docker/rhel-push-plugin
7189762f7c0b056eb63bbb50b347fa78d5fd1bed5a4ddad0cb80f2a97f8369c7:fedora/27/x86_64/atomic-host => cadb1ae8cc017ccab7566af022be32f5f55f5e781bb02a4363303e3a4631e28f : /boot/efi/EFI/BOOT/BOOTX64.EFI
fedora/27/x86_64/atomic-host => cadb1ae8cc017ccab7566af022be32f5f55f5e781bb02a4363303e3a4631e28f : /boot/efi/EFI/fedora/shim.efi
fedora/27/x86_64/atomic-host => cadb1ae8cc017ccab7566af022be32f5f55f5e781bb02a4363303e3a4631e28f : /boot/efi/EFI/fedora/shimx64.efi
7596c150eae25a9191eb74dd8a76bc7e630d74e6bcf18fd10ddb54a9948044ee:fedora/27/x86_64/atomic-host => cadb1ae8cc017ccab7566af022be32f5f55f5e781bb02a4363303e3a4631e28f : /usr/libexec/docker/docker-containerd-current
906f1875609e2c6d9bafcf20d7fada3efcf0630bb9b9af5ec69c970f0dcbf62b:fedora/27/x86_64/atomic-host => cadb1ae8cc017ccab7566af022be32f5f55f5e781bb02a4363303e3a4631e28f : /usr/libexec/docker/docker-runc-current
9d95dbc4d11ec409036bb3cba3b98860cd2062cd29db287adb77bc1f05989d99:fedora/27/x86_64/atomic-host => cadb1ae8cc017ccab7566af022be32f5f55f5e781bb02a4363303e3a4631e28f : /usr/lib/locale/locale-archive
a4b53e70cd7723e80adcf69c47951b4e863ae5ad3ae85038452efab7d09e1224:fedora/27/x86_64/atomic-host => cadb1ae8cc017ccab7566af022be32f5f55f5e781bb02a4363303e3a4631e28f : /boot/efi/EFI/fedora/fonts/unicode.pf2
aa54924a6324456a8c26f47bf6673a3d845573d744e3d4247ff01b40d24d8c49:fedora/27/x86_64/atomic-host => cadb1ae8cc017ccab7566af022be32f5f55f5e781bb02a4363303e3a4631e28f : /usr/libexec/docker/docker-proxy-current
c9b8a6cf250519c3f846561cdb86be9047f29708df985a68382e0e20d77ba57f:fedora/27/x86_64/atomic-host => cadb1ae8cc017ccab7566af022be32f5f55f5e781bb02a4363303e3a4631e28f : /usr/libexec/docker/docker-ctr-current
d48b064370104721ee23c08bac938ebb5fd7ebe338e6f7a36948a5204eff9661:fedora/27/x86_64/atomic-host => cadb1ae8cc017ccab7566af022be32f5f55f5e781bb02a4363303e3a4631e28f : /usr/libexec/docker/docker-containerd-shim-current
d5f0ef0e11324807830bec8bc30c9f32431b14a3e96f611492f9db1f8acda3b8:fedora/27/x86_64/atomic-host => cadb1ae8cc017ccab7566af022be32f5f55f5e781bb02a4363303e3a4631e28f : /usr/etc/selinux/targeted/active/policy.kern
fedora/27/x86_64/atomic-host => cadb1ae8cc017ccab7566af022be32f5f55f5e781bb02a4363303e3a4631e28f : /usr/etc/selinux/targeted/active/policy.linked
fedora/27/x86_64/atomic-host => cadb1ae8cc017ccab7566af022be32f5f55f5e781bb02a4363303e3a4631e28f : /usr/etc/selinux/targeted/policy/policy.31
e75bdeace7e09dcfc73df319eb0eb10bb357b706d30e9868f6912e9e515b5ada:fedora/27/x86_64/atomic-host => cadb1ae8cc017ccab7566af022be32f5f55f5e781bb02a4363303e3a4631e28f : /boot/efi/EFI/fedora/MokManager.efi
fedora/27/x86_64/atomic-host => cadb1ae8cc017ccab7566af022be32f5f55f5e781bb02a4363303e3a4631e28f : /boot/efi/EFI/fedora/mmx64.efi
fde8594944402b5894300c5ecf205ef66db849de6ec7fa791d91db8bf8fa9522:fedora/27/x86_64/atomic-host => cadb1ae8cc017ccab7566af022be32f5f55f5e781bb02a4363303e3a4631e28f : /usr/etc/udev/hwdb.bin

And of course the problem is:

# ostree --repo=repo-build ls -C -X fedora/27/x86_64/atomic-host /usr/bin/docker-current
-00755 0 0 13127696 4bfd2496187505fa91becc863881d1f44d5e18e54b26c5c3c449353a42502a45 { [(b'security.selinux', b'system_u:object_r:container_runtime_exec_t:s0')] } /usr/bin/docker-current
# ostree --repo=cache/pkgcache-repo ls -C -X rpmostree/pkg/docker/2_3A1.13.1-26.gitb5e3294.fc27.x86__64 /usr/bin/docker-current
-00755 0 0 13127696 19d357ff1bc79fb9418efbeb7a4dfa07d0bff37dd6113faafa036e8cf96c6916 { [(b'security.selinux', b'system_u:object_r:bin_t:s0')] } /usr/bin/docker-current

Reading the code a bit I think the reason this happens is the second rpmostree_context_relabel() is a noop as "packages to relabel" is a 0 length array. We need to have an rpmostree_context_force_relabel() or so?

cgwalters added a commit to cgwalters/rpm-ostree that referenced this issue Jan 2, 2018
Basically the `rpmostree_context_relabel()` call we had in the treecompose path
for unified core didn't actually have any effect as the core code did a relabel
and unset the array.

I think this may actually be a regression from: coreos#1137
though I didn't verify.

Anyways looking at this, the code is a lot simpler if we change the API so that
the "normal" relabeling is folded into `rpmostree_context_assemble()`. Then we
change the public relabel API to be "force relabel" which we use in the unified
core 🌐 treecompose path.

This shrinks the jigdoRPM for FAH from 90MB to 68MB.

Closes: coreos#1172
cgwalters added a commit to cgwalters/rpm-ostree that referenced this issue Jan 3, 2018
Basically the `rpmostree_context_relabel()` call we had in the treecompose path
for unified core didn't actually have any effect as the core code did a relabel
and unset the array.

I think this may actually be a regression from: coreos#1137
though I didn't verify.

Anyways looking at this, the code is a lot simpler if we change the API so that
the "normal" relabeling is folded into `rpmostree_context_assemble()`. Then we
change the public relabel API to be "force relabel" which we use in the unified
core 🌐 treecompose path.

This shrinks the jigdoRPM for FAH from 90MB to 68MB.

Closes: coreos#1172
@jlebon jlebon added the bug label Jan 5, 2018
cgwalters added a commit to cgwalters/rpm-ostree that referenced this issue Jan 6, 2018
Basically the `rpmostree_context_relabel()` call we had in the treecompose path
for unified core didn't actually have any effect as the core code did a relabel
and unset the array.

I think this may actually be a regression from: coreos#1137
though I didn't verify.

Anyways looking at this, the code is a lot simpler if we change the API so that
the "normal" relabeling is folded into `rpmostree_context_assemble()`. Then we
change the public relabel API to be "force relabel" which we use in the unified
core 🌐 treecompose path.

This shrinks the jigdoRPM for FAH from 90MB to 68MB.

Closes: coreos#1172
rh-atomic-bot pushed a commit that referenced this issue Jan 8, 2018
Basically the `rpmostree_context_relabel()` call we had in the treecompose path
for unified core didn't actually have any effect as the core code did a relabel
and unset the array.

I think this may actually be a regression from: #1137
though I didn't verify.

Anyways looking at this, the code is a lot simpler if we change the API so that
the "normal" relabeling is folded into `rpmostree_context_assemble()`. Then we
change the public relabel API to be "force relabel" which we use in the unified
core 🌐 treecompose path.

This shrinks the jigdoRPM for FAH from 90MB to 68MB.

Closes: #1172

Closes: #1173
Approved by: jlebon
rh-atomic-bot pushed a commit that referenced this issue Jan 8, 2018
Basically the `rpmostree_context_relabel()` call we had in the treecompose path
for unified core didn't actually have any effect as the core code did a relabel
and unset the array.

I think this may actually be a regression from: #1137
though I didn't verify.

Anyways looking at this, the code is a lot simpler if we change the API so that
the "normal" relabeling is folded into `rpmostree_context_assemble()`. Then we
change the public relabel API to be "force relabel" which we use in the unified
core 🌐 treecompose path.

This shrinks the jigdoRPM for FAH from 90MB to 68MB.

Closes: #1172

Closes: #1173
Approved by: jlebon
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Projects
None yet
Development

No branches or pull requests

2 participants