On Sunday, 22 April 2018 23:35:47 UTC+10, vic viq  wrote:
> On 18-04-22 05:26:35, trueriver wrote:
> > The page https://www.qubes-os.org/doc/qfilecopy/ decribes how to copy a 
> > file or directory to another domain. In the case of a directory the files 
> > can later be copied back, in which case they end up in a different 
> > directory than the original.
> > 
> > This has the advantage that both copies are available in the original host 
> > domain.
> > 
> > This has the disadvantage that copying may take some time, especially if 
> > there are a lot of files that were not actually changed.
> > 
> > I am wondering if there already exists the facility to bind a directory in 
> > one domain (the original domain) to one in another domain (the new domain). 
> > I envisage this working like mount --bind within a single machine. 
> 
> Random idea would be to create a file container, and either mount it
> locally with --loop, or (somehow...) use qvm-block to export the mount
> to another VM.

Not random at all. That is how I achieve it.
I mount one img file under multiple guests simultaneously.

So just the qvm-block will work.
If you want to get more in depth, use xl and set that up that way.
It can be more effective and speedy.


>  
> > This would have the advantage that edits made in the new domain would 
> > immediately be available in the original domain.
> > 
> > That would also be a security disadvantage as the attack surface now exists 
> > in both domains, but I envisage this being limited to the contents of the 
> > bound directory.
> > 
> > 1:
> > Has this idea been implemented already? If so pls post a link to some 
> > details.
> > 
> > 2:
> > If not, is there a way to copy back only the files that actually changed - 
> > like an inter domain rsync perhaps? If so, how would I do that?
> > 
> > This has the advantage of saving the redundant return copy, but still has 
> > the disadvantage of doing a forward copy on files that turn out to 
> > unnecessary.
> > 
> > 3:
> > Has the idea of an interVM bind been considered and rejected as inherently 
> > insecure?
> > 
> > 4:
> > Has this idea been considered and rejected as requiring more work than we 
> > want to do at the moment?

-- 
You received this message because you are subscribed to the Google Groups 
"qubes-users" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to qubes-users+unsubscr...@googlegroups.com.
To post to this group, send email to qubes-users@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/qubes-users/0433eae3-cf2c-41cc-9b6a-a5b9da09f7ec%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Reply via email to