On Wed, Sep 16, 2009 at 09:33:11PM -0700, Edward Pilatowicz wrote: > there by implying that the vdisk path is a directory. ok. that's easy
Right. > enough to detect. It's probably safer to directly use vdiskadm to sniff the directory, if you can. > > At import time, it's a combination of sniffing the type from the file, > > and some static checks on file name (namely .raw and .iso suffixes). > > well, as long as the suffixes above apply to directories and not to > files then i think we'd be ok. if the extensions above will apply to > files then we have a problem. Once imported, the contents of the vdisk directory are private to vdisk. The name of the containing directory can be anything. That is, an import consists of taking the foo.raw file, and putting it into a directory along with an XML properties file. > so previously if the user specified: > file:///.../foo.raw > then we would create a zpool directly within the file, no label. > > and if the user specified: > vfile:///.../foo.raw > > then we would use lofi with the newly proposed -l option to access the > file, then we'd put a label on it (via the lofi device), and then create > a zpool in one of the partitions (and once again, zfs would access the > file through the lofi device). > > so in the two cases, how can we make the access mode determination > without having the seperate uri syntax? In the creation case, which I think we're talking about above, we create the vdisk directory (rather than direct file access, which vdiskadm can't do, even though vdisk itself can) and the container format is clear. If we want to configure access to a pre-existing raw file, I'm not sure we'd be doing the labelling ourselves. Perhaps I don't quite understand the use cases for what you're suggesting. > > How about defaulting to the owner of the containing directory? If it's > > root, you won't be able to write if you're root-squashed (or not root > > user) anyway. > > > > Failing that, I'd indeed prefer a different user, especially one that's > > configurable in terms of uid/gid. > > if a directory is owned by a non-root user and i want to create a file > there, i think it's a great idea to switch to the uid of the directory > owner todo my file operations. i'll add that to the proposal. > > but, say i'm on a host that is not subject to root squashing and i need > to create a file on a share that is only writable by root. in that > case, should i go ahead and create a file owned by root? imho, no. > instead, i'd rather create the file as some other user. I don't agree that second-guessing the user's intentions when they've explicitly disabled root-squashing is a useful behaviour. > if the administrator then tries to migrate that zone to a host that is > subject to root squashing from the server, then i'd lose access to that > file. eliminating all file accesses as root allows us to avoid > root-squashing and just help eliminate potential failure modes. Replacing it with a potentially more subtle issue: what's the zonenfs user ID, is it configured on the server, and is it unique and reserved across the organisation, and across all OSes? Having access fail with a clear message is an understandable failure mode, with a clear remedy: use a suitable uid /chosen by the administrator/. NFS users are surely comfortable and familiar with root squashing by now. Having a MySQL security hole allow access to all your virtual shared storage is a much more subtle problem (yes, I discovered despite my initial research that UID 60 is used by some Linux machines as mysqld). regards john _______________________________________________ zones-discuss mailing list zones-discuss@opensolaris.org
