Re: [PATCH v2] docs: document file-posix locking protocol

[Vladimir Sementsov-Ogievskiy]

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.

--
Best regards,
Vladimir