16.07.2021 19:21, Vladimir Sementsov-Ogievskiy wrote:
15.07.2021 23:00, Vladimir Sementsov-Ogievskiy wrote:
03.07.2021 16:50, Vladimir Sementsov-Ogievskiy wrote:
+Permission bytes. If permission byte is rd-locked, it means that some process
+uses corresponding permission on that file.
+
+Byte Operation
+100 read
+ Lock holder can read
+101 write
+ Lock holder can write
+102 write-unchanged
+ Lock holder can write same data if it sure, that this write doesn't
+ break concurrent readers. This is mostly used internally in Qemu
+ and it wouldn't be good idea to exploit it somehow.
Let's make it more strict:
New software should never lock this byte and interpret this byte locked by
other process like write permission (same as 101).
[*]
+103 resize
+ Lock holder can resize the file. "write" permission is also required
+ for resizing, so lock byte 103 only if you also lock byte 101.
+104 graph-mod
+ Undefined. QEMU may sometimes locks this byte, but external programs
+ should not. QEMU will stop locking this byte in future
+
+Unshare bytes. If permission byte is rd-locked, it means that some process
+does not allow the others use corresponding options on that file.
+
+Byte Operation
+200 read
+ Lock holder don't allow read operation to other processes.
+201 write
+ Lock holder don't allow write operation to other processes. This
+ still allows others to do write-uncahnged operations. Better not
+ exploit outside of Qemu.
+202 write-unchanged
+ Lock holder don't allow write-unchanged operation to other processes.
And here, correspondingly:
New software should never lock this byte and interpret this byte locked by
other process like write permission unshared (same as 201).
Hmm, no. For [*] work correctly, new software should always lock 202 if it
locks 201.
+203 resize
+ Lock holder don't allow resizing the file by other processes.
+204 graph-mod
+ Undefined. QEMU may sometimes locks this byte, but external programs
+ should not. QEMU will stop locking this byte in future
+
+Handling the permissions works as follows: assume we want to open the file to
do
+some operations and in the same time want to disallow some operation to other
+processes. So, we want to lock some of the bytes described above. We operate as
+follows:
+
More on this.
Hmm, we can just drop graph-mod. I don't think it is needed now, and anyway no
sense in locking it in file-posix.
write-unchanged is rather strange here. One process may read data and write it back and
consider it WRITE_UNCHANGED, but other process may change the file intermediatly, and for
it the WRITE_UNCHANGED of first process is not "unchanged"..
It probably good to drop write-unchanged from the protocol at all. But what if
we have old qemu that can lock write-unchanged (byte 102) and not write (byte
101)? The audit do we really have such a case now or in some previous version
is rather hard to do..
So, if we want to support it in the most compatible way, all new software
should lock both 201 and 202 to unshare write.
Locking 102 in pair with 101 doesn't make real sense: if we has write access, we don't
need additional write-unchanged anyway. Still, we may document that these bytes should be
locked together just for consistency with "unshare" bytes.
Any thoughts?
Probably it worth also document that 203 is recommended to be locked if
application want to lock 201, to avoid bad behaving process, that locks 103 and
not 101 and thinks that it has permission to resize.
And one more question to consider.
What about read? Actually what's the sense of locking byte 200? What's wrong
for us if some other process access the file in RO mode?
In Qemu this permissin is called CONSISTENT_READ.. Who knows what it means? How
much consistent may be read by process A, when process B has write permission
and do write at the moment?
Hmm, looking at BLK_PERM_CONSISTENT_READ description, I see that it mostly
about intermediate nodes of commit block job. If we read from intermediate node
of commite block job we may read old data (original view of the node) or new
data (that was recently committed and actually unrelated to this intermediate
node that we are going to remove).
But I doubt that it make sense for interprocess syncrhonisation: if want to
read consistantly, we must unshare write on the whole backing chain.. And no
real sense in sharing READ..
Finally, it seems to me that only the following scenarios make sense:
1. read-only access, don't care about existing writing Qemu process: just open
RO, don't care about locks (like qemu-img --force-share)
2. RO or RW access, want consistency: unshare all operations, lock bytes 20*.
Than no real sense in locking any of 10*.. But for consistency and safety
better to lock them all.