files landed when installing system container have `default_t` label
miabbott opened this issue · 9 comments
miabbott commented
Starting with atomic-1.21.1-1.fc27.x86_64, files landed when installing a system container are ending up with the SELinux label of default_t
# rpm-ostree status
State: idle
Deployments:
● fedora-atomic:fedora/27/x86_64/testing/atomic-host
Version: 27.75 (2018-02-05 16:50:22)
Commit: 4fba4fb43a61dfef54ba3d98d7140e5aa91b1577d4fa09d746b1c73e18af41d9
GPGSignature: Valid signature by 860E19B0AFA800A1751881A6F55E7430F5282EE4
fedora-atomic:fedora/27/x86_64/atomic-host
Version: 27.44 (2018-01-01 21:54:31)
Commit: b5845ebd002b2ec829c937d68645400aa163e7265936b3e91734c6f33a510473
GPGSignature: Valid signature by 860E19B0AFA800A1751881A6F55E7430F5282EE4
# rpm -q atomic ostree
atomic-1.21.1-1.fc27.x86_64
ostree-2018.1-1.fc27.x86_64
# atomic pull --storage ostree registry.fedoraproject.org/f27/etcd
Getting image source signatures
Copying blob sha256:04331e646521ddb577d113f3c103aef620cc4451641452c347864298669f8572
86.07 MB / 86.07 MB [===================================================] 1m10s
Copying blob sha256:8d884f5d20c013d78d0be609bbc9dedbfa26de7d7b6f66d9e6422dc163ab0e2f
20.03 MB / 20.03 MB [======================================================] 0s
Copying config sha256:67a58c9856a5f5e99039c3b5b5de38ea9bb2fcdf1ebfe41125b74037ab90df45
4.44 KB / 4.44 KB [========================================================] 0s
Writing manifest to image destination
Storing signatures
# atomic --debug install --system --system-package=no --name etcd registry.fedoraproject.org/f27/etcd
Namespace(_class=<class 'Atomic.install.Install'>, args=[], assumeyes=False, debug=True, display=False, func='install', ignore=False, image='registry.fedoraproject.org/f27/etcd', name='etcd', opt1=None, opt2=None, opt3=None, profile=False, remote=None, runtime=None, setvalues=None, storage=None, system=True, system_package='no', user=False)
Extracting to /var/lib/containers/atomic/etcd.0
Created file /etc/etcd/etcd.conf
Created file /usr/local/bin/etcdctl
systemctl daemon-reload
systemd-tmpfiles --create /etc/tmpfiles.d/etcd.conf
systemctl enable etcd
# find /var -context '*:default_t:*'
/var/lib/containers/atomic/.storage/ostree/objects/1e/5348704a7b2bbce43f4dc93318c36dfbbb4e198868e4dc8ac5cc97c92a48ef.file
/var/lib/containers/atomic/.storage/ostree/objects/85/33ea573d69405e540fa6df08d37d881f3dcea353ba3ad40e6e5dffdb266782.file
/var/lib/containers/atomic/.storage/ostree/objects/80/189d9d36809cd427447df9cefd07e2f1175105d94c07ea4767dcd67d7e0dd6.file
/var/lib/containers/atomic/.storage/ostree/objects/ce/0aebf1721059bd81a002eebc2894cebb34e084ced3483b860689a612c113ea.file
/var/lib/containers/atomic/etcd.0/rootfs/exports/config.json.template
/var/lib/containers/atomic/etcd.0/rootfs/exports/manifest.json
/var/lib/containers/atomic/etcd.0/rootfs/exports/service.template
/var/lib/containers/atomic/etcd.0/rootfs/exports/tmpfiles.template
/var/lib/containers/atomic/etcd.0/rootfs/exports/hostfs
Previous versions of atomic would land those same files with the label container_share_t:
# rpm-ostree status
State: idle
Deployments:
● fedora-atomic:fedora/27/x86_64/atomic-host
Version: 27.72 (2018-01-31 21:28:04)
Commit: 39848372585a65dc63fb3052f997139b8b30d6b55ce378337db3664177489d28
GPGSignature: Valid signature by 860E19B0AFA800A1751881A6F55E7430F5282EE4
fedora-atomic:fedora/27/x86_64/atomic-host
Version: 27.44 (2018-01-01 21:54:31)
Commit: b5845ebd002b2ec829c937d68645400aa163e7265936b3e91734c6f33a510473
GPGSignature: Valid signature by 860E19B0AFA800A1751881A6F55E7430F5282EE4
# rpm -q atomic ostree
atomic-1.20.1-9.fc27.x86_64
ostree-2018.1-1.fc27.x86_64
# atomic pull --storage ostree registry.fedoraproject.org/f27/etcd
Getting image source signatures
Copying blob sha256:04331e646521ddb577d113f3c103aef620cc4451641452c347864298669f8572
86.07 MB / 86.07 MB [======================================================] 1s
Copying blob sha256:8d884f5d20c013d78d0be609bbc9dedbfa26de7d7b6f66d9e6422dc163ab0e2f
20.03 MB / 20.03 MB [======================================================] 6s
Copying config sha256:67a58c9856a5f5e99039c3b5b5de38ea9bb2fcdf1ebfe41125b74037ab90df45
4.44 KB / 4.44 KB [========================================================] 0s
Writing manifest to image destination
Storing signatures
# atomic --debug install --system --system-package=no --name etcd registry.fedoraproject.org/f27/etcd
Namespace(_class=<class 'Atomic.install.Install'>, args=[], assumeyes=False, debug=True, display=False, func='install', ignore=False, image='registry.fedoraproject.org/f27/etcd', name='etcd', opt1=None, opt2=Non
e, opt3=None, profile=False, remote=None, runtime=None, setvalues=None, storage=None, system=True, system_package='no', user=False)
Extracting to /var/lib/containers/atomic/etcd.0
Created file /etc/etcd/etcd.conf
Created file /usr/local/bin/etcdctl
systemctl daemon-reload
systemd-tmpfiles --create /etc/tmpfiles.d/etcd.conf
systemctl enable etcd
# find /var -context '*:default_t:*'
# echo $?
0
# ls -lZ /var/lib/containers/atomic/etcd.0/rootfs/exports/
total 20
-rw-r--r--. 2 root root unconfined_u:object_r:container_share_t:s0 6038 Jan 1 1970 config.json.template
drwxr-xr-x. 4 root root unconfined_u:object_r:container_share_t:s0 28 Jan 1 1970 hostfs
-rw-r--r--. 2 root root unconfined_u:object_r:container_share_t:s0 1485 Jan 1 1970 manifest.json
-rw-r--r--. 2 root root unconfined_u:object_r:container_share_t:s0 213 Jan 1 1970 service.template
-rw-r--r--. 2 root root unconfined_u:object_r:container_share_t:s0 231 Jan 1 1970 tmpfiles.template
miabbott commented
@giuseppe tells me this may actually be a skopeo issue.
The 'working' version of skopeo is skopeo-0.1.27-1.git93876ac.fc27.x86_64
The broken version used is skopeo-0.1.28-1.git0270e56.fc27.x86_64
giuseppe commented
looking better at the logs, it looks like you already had some layers pre-pulled (with a prior version of Skopeo) that didn't have the SELinux label. The SELinux label is assigned at pull time when the image is first added to the storage.
Could you try to nuke the /var/lib/containers/atomic/.storage before pulling the image, or ostree refs --delete ociimage if it is shared with the system?
We probably need to add some metadata to the pulled layers so that we know what version of Skopeo pulled them and re-pull once we try with a newer version.
miabbott commented
Could you try to nuke the /var/lib/containers/atomic/.storage before pulling the image, or ostree refs --delete ociimage if it is shared with the system?
Didn't work out so well...
# rpm-ostree status
State: idle
Deployments:
● fedora-atomic:fedora/27/x86_64/testing/atomic-host
Version: 27.75 (2018-02-05 16:50:22)
Commit: 4fba4fb43a61dfef54ba3d98d7140e5aa91b1577d4fa09d746b1c73e18af41d9
GPGSignature: Valid signature by 860E19B0AFA800A1751881A6F55E7430F5282EE4
fedora-atomic:fedora/27/x86_64/atomic-host
Version: 27.72 (2018-01-31 21:28:04)
Commit: 39848372585a65dc63fb3052f997139b8b30d6b55ce378337db3664177489d28
GPGSignature: Valid signature by 860E19B0AFA800A1751881A6F55E7430F5282EE4
# rpm -q atomic ostree skopeo
atomic-1.21.1-1.fc27.x86_64
ostree-2018.1-1.fc27.x86_64
skopeo-0.1.28-1.git0270e56.fc27.x86_64
# rm -rf /var/lib/containers/atomic/.storage
# atomic pull --storage ostree registry.fedoraproject.org/f27/etcd
Getting image source signatures
Copying blob sha256:04331e646521ddb577d113f3c103aef620cc4451641452c347864298669f8572
86.07 MB / 86.07 MB [======================================================] 1s
Copying blob sha256:8d884f5d20c013d78d0be609bbc9dedbfa26de7d7b6f66d9e6422dc163ab0e2f
20.03 MB / 20.03 MB [======================================================] 3s
Copying config sha256:67a58c9856a5f5e99039c3b5b5de38ea9bb2fcdf1ebfe41125b74037ab90df45
4.44 KB / 4.44 KB [========================================================] 0s
Writing manifest to image destination
Storing signatures
# atomic install --system --system-package=no --name etcd registry.fedoraproject.org/f27/etcd
Extracting to /var/lib/containers/atomic/etcd.0
Created file /etc/etcd/etcd.conf
Created file /usr/local/bin/etcdctl
systemctl daemon-reload
systemd-tmpfiles --create /etc/tmpfiles.d/etcd.conf
systemctl enable etcd
# find /var -context '*:default_t:*'
/var/lib/containers/atomic/.storage/ostree/objects/1e/5348704a7b2bbce43f4dc93318c36dfbbb4e198868e4dc8ac5cc97c92a48ef.file
/var/lib/containers/atomic/.storage/ostree/objects/85/33ea573d69405e540fa6df08d37d881f3dcea353ba3ad40e6e5dffdb266782.file
/var/lib/containers/atomic/.storage/ostree/objects/80/189d9d36809cd427447df9cefd07e2f1175105d94c07ea4767dcd67d7e0dd6.file
/var/lib/containers/atomic/.storage/ostree/objects/ce/0aebf1721059bd81a002eebc2894cebb34e084ced3483b860689a612c113ea.file
/var/lib/containers/atomic/etcd.0/rootfs/exports/config.json.template
/var/lib/containers/atomic/etcd.0/rootfs/exports/manifest.json
/var/lib/containers/atomic/etcd.0/rootfs/exports/service.template
/var/lib/containers/atomic/etcd.0/rootfs/exports/tmpfiles.template
/var/lib/containers/atomic/etcd.0/rootfs/exports/hostfs
giuseppe commented
these files are fine with default_t as they are metadata for installing and managing the system container.
rhatdan commented
Well any confined domain will not be able to use them including confined containers.
giuseppe commented
these are used by "atomic install" that is privileged and by runc/oci runtime before it launches the container.
I can prepare a patch for containers/image to avoid any problem later on, what label should we use for these metadata files?
giuseppe commented
@rhatdan, should I use unconfined_u:object_r:container_var_lib_t:s0 for these files?
giuseppe commented
I submitted a patch for container-selinux:
rhatdan commented
I think container_var_lib_t might make the most sense.