Merge lp:~danilo/vmbuilder/bug-536940 into lp:vmbuilder
Status: | Merged | ||||
---|---|---|---|---|---|
Approved by: | Soren Hansen | ||||
Approved revision: | 455 | ||||
Merged at revision: | 447 | ||||
Proposed branch: | lp:~danilo/vmbuilder/bug-536940 | ||||
Merge into: | lp:vmbuilder | ||||
Diff against target: |
177 lines (+70/-22) 2 files modified
VMBuilder/contrib/cli.py (+40/-10) VMBuilder/util.py (+30/-12) |
||||
To merge this branch: | bzr merge lp:~danilo/vmbuilder/bug-536940 | ||||
Related bugs: |
|
Reviewer | Review Type | Date Requested | Status |
---|---|---|---|
Soren Hansen | Approve | ||
Review via email:
|
Commit message
(Re-)Add --tmpfs and --tmp options to vmbuilder.
Description of the change
= Bug 536940 =
So, this re-introduces a --tmpfs and --tmp options. I'm not entirely sure of the syntax for --tmpfs, so I implemented what seems to have been the idea according to the documentation and old web site snippets I found. I'd probably prefer it if it was two options ("--use-tmpfs" and "--tmpfs-size"), but I don't have the time to implement that.
I've also simplified util.tmpfile and util.tmpdir functions: they were always called with the same value of 'keep' parameter. I'd be either leaning on removing them altogether, or making them useful for something (like providing a standard vmbuilder prefix like "vmbuilder" :): they are now single-line calls to tempfile module, and we should just use it directly then.
I've done a few more cleanups of my own code as well since I first written it up: I've removed catching of VMBuilderUserError exception because a run_cmd exception will contain much more useful information than my error message in util.set_up_tmpfs and util.clean_
There is also one thing I am unsure about: I'm unmounting a tmpfs even when an error occurs, but that means that you can't go into a chroot and figure out what went wrong. I found that more useful (and when I did hit a problem that needed me to go into chroot directly, and wasn't just an error on my part, I simply ran it without --tmpfs option), but I can easily be convinced the opposite.
FWIW, that sys.exit(1) call is removed simply because it's never executed with a raise just before it.
Note: I won't have much time to work on this. For instance, to actually make tmpfile calls safer, we'd at least do the following: actually create a file using tempfile.mkstemp(), and remove it only just prior to doing the operation which is going to write to that file. That wouldn't remove the risks, would just make them much, much smaller. Of course, I understand that vmbuilder is not designed to be run on machines with untrusted users, so even if I had time to spend on it, I don't think it'd be worthwhile.
On Thu, Jun 10, 2010 at 05:22:23PM -0000, Данило Шеган wrote:
> I've also simplified util.tmpfile and util.tmpdir functions: they were
> always called with the same value of 'keep' parameter.
Ah, good catch. This probably hasn't been the case all along, but I
can't think of an easy way to discover that a particular interface is no
longer used. :(
> I'd be either leaning on removing them altogether, or making them
> useful for something (like providing a standard vmbuilder prefix like
> "vmbuilder" :): they are now single-line calls to tempfile module, and
> we should just use it directly then.
I'm in favour of the vmbuilder prefix idea. It would make cleaning up
after VMBuilder during development easier as well.
> There is also one thing I am unsure about: I'm unmounting a tmpfs even
> when an error occurs, but that means that you can't go into a chroot
> and figure out what went wrong. I found that more useful (and when I
> did hit a problem that needed me to go into chroot directly, and
> wasn't just an error on my part, I simply ran it without --tmpfs
> option), but I can easily be convinced the opposite.
Historically, VMBuilder would clean up very well after itself. This was
slightly annoying during development (as you've identified), and it also
had some unfortunate side effects (it would delete people's /dev (in the
host) in some cases). In 0.12.x a lot of these cleanup procedures are
simply not run at all. What I would like, really, is to be able to pass
a --development option or set an environment variable or something that
would make VMBuilder not clean up after itself at all, but for
end-users, even in case of errors, it would clean up.
> Note: I won't have much time to work on this. For instance, to
> actually make tmpfile calls safer, we'd at least do the following:
> actually create a file using tempfile.mkstemp(), and remove it only
> just prior to doing the operation which is going to write to that
> file. That wouldn't remove the risks, would just make them much, much
> smaller.
Alternatively, we could create a temporary directory with mkdtemp with
mode 0700 and use that as the base directory for all the subsequent
temporary files. That way we avoid the race condition, because there's
simply no way another user could a file in there.
> Of course, I understand that vmbuilder is not designed to be run on
> machines with untrusted users, so even if I had time to spend on it, I
> don't think it'd be worthwhile.
Well, it's not meant to make any assumptions ot the opposite either, so
if someone wants to take a stab at this, that would be great.
The patch looks fine. Thanks!
review +1
merge approved
-- www.ubuntu. com/
Soren Hansen
Ubuntu Developer
http://