On 06/14/2017 03:11 PM, Marek Marczykowski-Górecki wrote:
> On Wed, Jun 14, 2017 at 03:03:00AM -0700, Andrew Morgan wrote:
>> Hey everyone, another week another progress report.
> 
>> As always, you can find the report with screenshots here:
>> https://blog.amorgan.xyz/gsoc-weekly-progress-report-2.html
> 
>> Otherwise the text-only version is reproduced below:
> 
>> ---
> 
>> The work this week consisted of finishing off the context menus within
>> Nautilus and Dolphin. I'm happy to report that they've both been
>> finished off and accompanied by some icons from GNOME's Adwaita icon set.
> 
>> They actually work now too :)
> 
>> Some screenshots below:
> 
>> [] Icons appear in menu items now in Nautilus
> 
>> [] We also have a checkmark icon to indicate to the user that a folder
>> is marked as untrusted
> 
>> [] The popup menu now includes the name of the file that is being marked
>> as well as the file type
> 
> This window could use some better title ;)

Derp, so focused on the window content I didn't even notice I hadn't
changed that yet :P

> 
>> [] Handy icons now show up on untrusted files!
> 
> (...)
> 
>> # Denying Local Read Permissions on Untrusted Files
> 
>> To prevent this mark otherwise being accidentally destroyed on the
>> originating VM, we can simply deny all users permission to read or write
>> from it (through a chmod 0). Props to my mentor Marek for the suggestion.
> 
>> This has the one hiccup of which we can no longer read a file's Extended
>> File Attributes, however our code can simply 'unlock' the file before
>> processing it by chmod'ing the file back to 0644 before processing, and
>> 'locking' it again afterwards.
> 
> Also worth checking how other file manager actions handle this - moving
> file, viewing its properties, copying it...
> And even if copying do work, check if xattrs are preserved.

Well as we `chmod 0` the file copying won't work as the file cannot be
read. This may present some UX issues, and we should inform the user
that a file must be 'unlocked' first before it can be moved.

>From my testing xattrs are preserved in Nautilus when
copying/moving/renaming, while Dolphin preserves it with renaming and
moving, but not copying.

We /could/ provide functionality in our extensions to move/copy/rename
the file such that it would be able to unlock and relock the file. I
could add this to the list of stretch goals perhaps.

> 
>> # Conclusion
> 
>> Now that the GUI is all finished, it's time to work on making the File
>> Managers (Nautilus and Dolphin) aware of untrusted files. While it's
>> easy enough to check for untrusted files on a right-click basis, we also
>> need to check their status on a single or double left-click (i.e when a
>> file is opened).
> 
>> Originally I planned to patch the File Managers to allow for running
>> code on a left-click, however after creating the Nautilus extension, it
>> seems to already do this by default. Coupled with the fact that files
>> are no longer locally editable and thus cannot be opened automatically,
>> we may not actually need to patch Nautilus at all!
> 
> \o/

So turns out while we do get a ping in our extension when a user tries
to open a file, we still need to prevent the file from attempting to be
opened - otherwise a rather annoying message will pop up complaining it
can't be read.

Additionally, I'm not entirely sure if the ping we receive is
indistinguishable from the one we get when a user right-clicks a file.

So patching will still be necessary to:

1. Prevent opening of the file all-together.
2. Send a separate message to the extension that a user is opening a
file, versus just clicking on it. (there may be a workaround for this
one, still looking)

> 
>> Dolphin may still require a patch, but I'll be looking for ways to
>> possibly get away with not needing to while working on the Nautilus
>> version first.
> 
>> Any and all feedback is appreciated, see you all in a week!
> 
> 
> 


-- 
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/ohsnc8%24qqv%241%40blaine.gmane.org.
For more options, visit https://groups.google.com/d/optout.

Attachment: signature.asc
Description: OpenPGP digital signature

Reply via email to