On 03/15/2017 06:47 PM, Marek Marczykowski-Górecki wrote: > On Wed, Mar 15, 2017 at 06:44:14PM -0700, Andrew Morgan wrote: >> On 03/15/2017 06:40 PM, Marek Marczykowski-Górecki wrote: >>> On Wed, Mar 15, 2017 at 09:13:22PM -0400, Jean-Philippe Ouellet wrote: >>>> On Wed, Mar 15, 2017 at 8:49 PM, Andrew Morgan >>>> <[email protected]> wrote: >>>>> On 03/15/2017 05:20 PM, Jean-Philippe Ouellet wrote: >>>>>> The task then would be to extend qfilecopy [1] to transfer these >>>>>> attributes >>>>> >>>>> In the issue on the GSoC page it states: >>>>> >>>>>> Allow setting persistent flag for a file that should be opened in >>>>>> specific way (“locally”); this flag should local to the VM - it >>>>>> shouldn’t be possible to preserve (or even fabricate) the flag while >>>>>> transferring the file from/to VM. >>>>> >>>>> I assuming by this bullet point we don't want the attribute transferred? >>>>> From my own testing the flags are already stripped when using qfilecopy, >>>>> thus we shouldn't have to do any work here, unless I'm misunderstanding >>>>> you? :) >>> >>>> I have not thought this through, and defer to those who have. >>> >>> Definitely we don't want a VM to make a file in other VM already marked >>> as "trustworthy, open locally" (or avoiding marking as >>> "untrusted, open in Disposable VM", if that would be the default action). >>> >>> In some cases one VM may "trust" some other VM, but I don't think it >>> justifies allowing transfer of such attributes. If anything, better add >>> a configuration to exclude certain QubesIncoming/some-vm from automatic >>> marking as untrusted. But not if it's a good idea either. >>> >>> > >>>> In some cases one VM may "trust" some other VM, but I don't think it >>>> justifies allowing transfer of such attributes. If anything, better add >>>> a configuration to exclude certain QubesIncoming/some-vm from automatic >>>> marking as untrusted. But not if it's a good idea either. > >> Presumably the user could choose to mark a folder as untrusted (or >> toggle it trusted) through the relevant file-manager options. > >> We could set ~/Downloads and all of ~/QubesIncoming as Untrusted by >> default and they could progressively "trust" incoming VMs by toggling >> the option off on the VM folders. > >> The only problem I could see with that is if they want to trust a VM >> that hasn't sent a file yet. The folder for that VM thus does not exist >> yet... > > But you can simply create it, right? > >
Yes, and with a daemon watching the ~/QubesIncoming folder, it should be marked as untrusted by default whether the user or system created it. Andrew Morgan -- You received this message because you are subscribed to the Google Groups "qubes-devel" group. To unsubscribe from this group and stop receiving emails from it, send an email to [email protected]. To post to this group, send email to [email protected]. To view this discussion on the web visit https://groups.google.com/d/msgid/qubes-devel/oacqv3%24pms%241%40blaine.gmane.org. For more options, visit https://groups.google.com/d/optout.
signature.asc
Description: OpenPGP digital signature
