Re: [libvirt] [PATCH v3 04/13] security_manager: Rework metadata locking
On 11/09/2018 03:47 PM, John Ferlan wrote:
So, then I assume the disks are shared because they've been
allowed in
two domains that are allowed to be running at the same time. If they're
shared and domainA has/uses a different label than domainB, then who
"wins" that war in the long run? Seems to me shared disks are
"dangerous" in this labeling game (and that's beyond the locking game).
The fact that a disk changes DAC label does not necessarily mean that
qemu is losing access. Firstly, the it might be just UID that changes on
the file and GID staying the same. Secondly, there might be an ACL entry
that lets qemu in no matter what. I agree that the disk should be marked
as shareable and readonly, but it's not for this code to decide.
Actually, it is not for libvirt to tell at all. Parsing UIDs is complex
and there's pretty good implementation in kernel so might as well rely
on that instead of duplicating the code into libvirt. IOW, if users
misconfigure disks to their domains and get EPERM or cut off access to
an already running domain, it's their problem and we shouldn't mitigate
it. On the other hand, we shouldn't just deadlock.
Should a mechanism be created to disallow multiple threads from running
the SetAllLabel "simultaneously" to avoid/solve the problem? Since it's
really the only one with the ordering problem...
This would hurt performance IMO. If there are two domains being started
at once and they don't share any common path then there is no reason for
relabel operation to run serialized.
Seems we each have our doom and gloom scenarios in mind ;-)
Thanks for the details -
John
Michal