On Tue, Oct 06, 2020 at 19:36:03 +0100, Brian Turek wrote: > Peter Krempa wrote: > > Since the qemu command line option is formatted as 4 octal digits, a > > mode such as '1775' which is a valid mode for a directory will still be > > formatted as something which looks like a decimal number: > > > > -fsdev > local,security_model=mapped,dmode=1775,id=fsdev-fs1,path=/export/fs1 \ > > > > Also the documentation doesn't mention whether sticky bit and such are > > actually handled. > > This is totally fair. QEMU has zero documentation on the intended limits on > these two options but the QEMU source masks them with 0777. Given that we > only have the implementation to go off of rather than the intent, should we > assume that sticky bits will never be supported or that it's an > unintentional > shortcoming in the QEMU code? > > I can either do similar masking or mask with 07777 and send along the > results > to QEMU as a 5-digit number (the first digit being a leading 0) .The > libvirt docs > could then say the behavior is ultimately determined by QEMU but, currently, > sticky bits are not supported? If it's unclear what qemu does, we can always just limit the values to 0777 ourselves for now as that's known and is potentially more strict than what qemu can do. The validation code then needs to make sure that it's in the correct range and thus the command line formatter will work correctly in the state it's now. So I'd go with a limit check in the validator and docs. I also presume that mode '0000' is not useful in this case. The code as it's now doesn't allow setting 0000 as the value is used as default when user didn't provide any mode.
