On Mon, Sep 21, 2009 at 04:25:30PM +0100, John Levon wrote:
> 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
> > 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 in this context, an import is one method for creating a vdisk.
> > 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
> 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.
the two use cases above were creation use cases.
i think part of the confusion here is that in the raw case, i thought a
vdisk would just have a file, not a directory with an xml file and the
disk file. (when i was using xvm that was the format of all the vdisks
the other part of the confusion is that i was trying to support
automatic creation for raw vdisks.
if we only support vdisks created via vdiskadm(1m), then we'll always
have a directory and we can always use vdiskadm(1m) to sniff out if it's
a valid vdisk and access it as such.
then for the implicit creation case we'll just support files containing
> > > 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).
ok. so how about we just generate an error if we need to create a file,
and an explicity user id has not been specified, and root squashing is
enabled. (because under these conditions we'd generate a file owned by
zones-discuss mailing list