New in the DCAP 1.26 release, the systemd service for qgsd has a "UMask=0117" set:
https://github.com/intel/confidential-computing.tee.dcap/blob/main/QuoteGeneration/installer/linux/common/tdx-qgs/startup.sh#L70
This is a pretty odd choice, as it means directories that the qgs daemon creates will have execute permission removed.
For example
$ ls -ald ~/.dcap-qcnl
drw-rw----. 1 qgs qgs 0 Jul 24 09:34 /var/lib/qgs/.dcap-qcnl
$ ls -al ~/.dcap-qcnl
ls: cannot access '/var/lib/qgs/.dcap-qcnl/.': Permission denied
ls: cannot access '/var/lib/qgs/.dcap-qcnl/..': Permission denied
total 0
d????????? ? ? ? ? ? .
d????????? ? ? ? ? ? ..
This in turn prevents qgs for saving a cache of PCKs it acquires
Jul 24 09:34:39 virtlab2406.virt.eng.rdu2.dc.redhat.com qgs[5961]: [QCNL] Created new cache directory: /var/lib/qgs/.dcap-qcnl/
Jul 24 09:34:39 virtlab2406.virt.eng.rdu2.dc.redhat.com qgs[5961]: [QCNL] Failed to write cache file '/var/lib/qgs/.dcap-qcnl//9dd79fdbf1d86594123e69389d852abc3db7bc661c5f77f43cc6ef9daad08805'.
Related to this, the qgs daemon now defaults to the UNIX socket transport (which is good), however, it hardcodes mode 0660 and documents that clients (such as QEMU) must be made a member of the 'qgsd' group (or equivalent if distro doesn't use that name).
Conceptually this makes sense a mechanism to avoid making the QGS socket available to all processes on the host OS, however, 'qgsd' is the group that qgs executes under, so care must be take to ensure no files owned by that process are group writable. IOW, the umask must use '7' in the group component, otherwise QEMU would potentially get write access to files cached under $HOME/.dcap-qcnl which is certainly not desirable.
IOW, I think only one of the following options makes sense:
- the systemd unit file umask needs changing to "0077", and socket_mode left on 0660
- the systemd unit file umask needs changing to "0007", and socket_mode relaxed to 0666
New in the DCAP 1.26 release, the systemd service for qgsd has a "UMask=0117" set:
https://github.com/intel/confidential-computing.tee.dcap/blob/main/QuoteGeneration/installer/linux/common/tdx-qgs/startup.sh#L70
This is a pretty odd choice, as it means directories that the qgs daemon creates will have execute permission removed.
For example
This in turn prevents qgs for saving a cache of PCKs it acquires
Related to this, the qgs daemon now defaults to the UNIX socket transport (which is good), however, it hardcodes mode 0660 and documents that clients (such as QEMU) must be made a member of the 'qgsd' group (or equivalent if distro doesn't use that name).
Conceptually this makes sense a mechanism to avoid making the QGS socket available to all processes on the host OS, however, 'qgsd' is the group that qgs executes under, so care must be take to ensure no files owned by that process are group writable. IOW, the umask must use '7' in the group component, otherwise QEMU would potentially get write access to files cached under $HOME/.dcap-qcnl which is certainly not desirable.
IOW, I think only one of the following options makes sense: