Re: [Nbd] [PATCH] Add "temporary" option, and ability to create files.

[Alex Bligh <alex@...872...>]

Wouter,

> Search for 'virtstyle' in the manpage (though I have received vague bug
> reports that it would be broken; I have not been able to confirm that
> yet)
>
> Granted, that's limited to one file per client. I suppose it could make
> sense to have a 'virtstyle = script' wich would let a script define a
> name, which it would have to report through stdout; that would also be
> useful with other things.

I think virtsyle does something different. Virtstyle effectively
adds a directory prefix based on client IP to the export filename.
Temporary makes the file (a) not read an existing file, and (b)
go away afterwards.

Some problems with using virtstyle for this are:

a) security: the whole export shares a single authentication point, so
  to read someone else's disk, all you have to do is steal their
  IP address (trivial). Even with a script to rm the file afterwards
  (see below for the problem with this) there is a race whereby a new
  connect will undetectably get the new file.

b) security again. Any user from a given IP (even an unpriviliged one)
  can (in theory) get access to the data concerned.

c) identification by IP address only allows one disk per IP and
  breaks with NAT (not that I can imagine NAT being used that often).

d) The disk is left around if nbd-server is crashed (including
  crashed intentionally). The temporary option doesn't suffer
  this because the file is unlinked as soon as it is opened,
  so the process ending will reliably free the file AND make
  sure no-one else can access it.

I'm not going to make a big fuss over this as it's hardly a must-have
feature. However, it does rather simplify writing test scripts! Given
it's non-invasive, and arguably useful in a production environment,
I think it's worth putting in.

> > did some
> > patches of my own, committed them to my tree, then noticed the
> > patch in master broke it. I couldn't see an obvious way to
> > revert a patch in such a way that it didn't appear in the
> > history, but still keep my own git history
>
> You want 'git rebase'. See 'git help rebase'; there's an example in
> there for how to deliberately lose some commits, too.

With apologies for using you as git support, is that possible even
if I've pushed to git.alex.org.uk? I'm worried about this comment:

> Rebasing (or any other form of rewriting) a branch that others have based
> work on is a bad idea


--
Alex Bligh