Re: [qubes-users] questions - InterVM directory bind
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.
Re: [qubes-users] questions - InterVM directory bind
On 2018-04-22 12:26, 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. > Someone was working on a FUSE driver that would work through qrexec / Qubes services. You might want to look into the mailing list archives for that. It seems very practical (if a bit insecure?) to share VM A's folder /x/y/z with VM B so that it appears as a mounted drive in VM B. -- Rudd-O http://rudd-o.com/ -- 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/1c7620f3-69c8-5c47-4f2c-6403e8fc20dd%40rudd-o.com. For more options, visit https://groups.google.com/d/optout.
Re: [qubes-users] questions - InterVM directory bind
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. > 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/20180422133542.wrgn4hzm4vhzrqas%40hirauchi. For more options, visit https://groups.google.com/d/optout.
