On 05/07/2013 02:28 PM, mdroth wrote: >> >> This points out that: >> >> 1. the documentation for guest-file-open is insufficient to describe our >> limitations (for example, although C11 requires support for the "wx" >> flag, this patch forbids that flag) > > Got a pointer? I can fix up the docs if need be, but fopen() docs that > qemu-ga points at seem to indicate 0666 will be used for new files. > That's no longer the case?
C99 and C11 don't care about permission bits of files created by fopen() - that's a concept added by POSIX. POSIX says that fopen() creates new files with respect to the current umask settings (in other words, 0666 minus bits that umask forbids). But since we weren't forbidding any bits, that meant we were getting 0666 files. http://pubs.opengroup.org/onlinepubs/9699919799/functions/fopen.html This patch intentionally leaves things unchanged so that any file created via guest-file-open still has mode 0666, just as it was pre-patch (it's just that the mode bits are now set via fchmod instead of implied via a umask of 0). But pre-patch, we handed any string on to fopen (whether bogus, such as "read", or valid C11, such as "wx", or even glibc extension, such as "we") and whether it succeeded or failed was dependent on the extensions supported in the version of libc running the guest agent. Now post-patch, we only accept a finite set of mode strings (those documented in C99) and explicitly reject others, even if they used to succeed. The documentation in qga/qapi-schema.json doesn't mention anything about the permissions given to created files (other than what you can infer by chasing down the POSIX rather than the C99 definition of fopen), and it only says that @mode is as per fopen() without saying whether it is C99 or C11 fopen(). > >> >> 2. guest-file-open is rather puny; we may need a newer interface that >> allows the user finer-grained control over the actual mode bits set on > > Yes, shame it wasn't there at the start. a guest-file-open-full or > something with support for specifying creation mode will have to do it. It boils down to fopen() mode argument being puny when compared to open()'s bit flags and optional mode_t argument. We inherently limited ourselves by designing after the higher-level C interface instead of the lower-level POSIX interface. So yes, hopefully when we design a new more powerful qga command, we will put more thought into designing it to do everything that we really want. -- Eric Blake eblake redhat com +1-919-301-3266 Libvirt virtualization library http://libvirt.org
signature.asc
Description: OpenPGP digital signature