On Sat, Jun 5, 2010 at 10:50 PM, Venkateswararao Jujjuri (JV) <jv...@linux.vnet.ibm.com> wrote: > Blue Swirl wrote: >> On Sat, Jun 5, 2010 at 1:08 AM, Venkateswararao Jujjuri (JV) >> <jv...@linux.vnet.ibm.com> wrote: >>> This patch series introduces the security model for VirtFS. >>> >>> Brief description of this patch series: >>> >>> It introduces two type of security models for VirtFS. >>> They are: mapped and passthrough. >>> >>> The following is common to both security models. >>> >>> * Client's VFS determines/enforces the access control. >>> Largely server should never return EACCESS. >>> >>> * Client sends gid/mode-bit information as part of creation only. >>> >>> Changes from V4 >>> --------------- >>> o Most of the cosmetic changes proposed by Aneesh. >>> o Divided into more number of patches and added more explanation to each >>> patch. >>> >>> Changes from V3 >>> --------------- >>> o Return NULL instead of exit(1) on failure in virtio_9p_init() >>> o Capitalized sm_passthrough, sm_mappe >>> o Added handling for EINTR for read/write. >>> o Corrected default permissions for mkdir in mapped mode. >>> o Added additional error handling. >>> >>> Changes from V2 >>> --------------- >>> o Removed warnings resulting from chmod/chown. >>> o Added code to fail normally if secuirty_model option is not specified. >>> >>> Changes from V1 >>> --------------- >>> o Added support for chmod and chown. >>> o Used chmod/chown to set credentials instead of setuid/setgid. >>> o Fixed a bug where uid used instated of uid. >>> >>> >>> Security model: mapped >>> ---------------------- >>> >>> VirtFS server(QEMU) intercepts and maps all the file object create requests. >>> Files on the fileserver will be created with QEMU's user credentials and the >>> client-user's credentials are stored in extended attributes. >>> During getattr() server extracts the client-user's credentials from extended >>> attributes and sends to the client. >>> >>> Given that only the user space extended attributes are available to regular >>> files, special files are created as regular files on the fileserver and the >>> appropriate mode bits are stored in xattrs and will be extracted during >>> getattr. >>> >>> If the extended attributes are missing, server sends back the filesystem >>> stat() unaltered. This provision will make the files created on the >>> fileserver usable to client. >>> >>> Points to be considered >>> >>> * Filesystem will be VirtFS'ized. Meaning, other filesystems may not >>> understand the credentials of the files created under this model. >>> >>> * Regular utilities like 'df' may not report required results in this model. >>> Need for special reporting utilities which can understand this security >>> model. >> >> Just some thought: This part could have other uses too, for example >> vext3 would be more useful than vvfat. Also VFAT attributes >> hidden/system/archived could be implemented with extended attributes. >> >> Another point to consider is that this will be Linux specific, if my >> earlier patch to make v9fs available to all Posix systems makes sense, >> this part should be conditional. > > The protocol we are developing is 9P2000.L, which is Linux specific protocol. > You mean there could be some Posix systems that doesn't support extended > attributes? > > As per this page BSDs and other systems also support extended attributes. > http://en.wikipedia.org/wiki/Extended_file_attributes
It looks like OpenBSD and NetBSD attributes are just a few fixed additional bits, much like old ext2 file attributes. > I think it is good point that before we are taking the patch to make it > generic for all > Posix systems, may be enable per OS and start with Linux? may be we should > wait until it becomes more stable and feature complete on Linux? before > considering for other OSes? Historically the interest from BSD developers (in form of acceptably submitted patches) has not been massive, so I wouldn't hold my breath waiting for any BSD (or any non-Linux) attribute patches either. Please go ahead and don't let me slow you down.
