Re: multiroot-filechooser ready for merging
On Wed, 2010-10-06 at 16:24 -0500, Federico Mena Quintero wrote: On Wed, 2010-10-06 at 21:01 +0100, Bastien Nocera wrote: Symbolic links? To both the filesystem itself, and to directories under ~/.gvfs/. Are those blocked as expected? Looks like we have different expectations ;) Then I would play down the security benefits of the features in the documentation... ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: multiroot-filechooser ready for merging
On Wed, Oct 6, 2010 at 3:06 PM, Federico Mena Quintero feder...@ximian.com wrote: Hi, all, I've been running Christian Hammond's multiroot-filechooser branch for about a month now, with zero ill effects. This is not surprising, as no apps actually use the multirooting functionality yet; what is nice is that those apps haven't broken yet. The past discussion is in bug #609886. I took the original multiroot-filechooser-2-20 branch and rebased it on top of master, and pushed the result as a new multiroot-filechooser branch. This is ready for merging into master, for 3.0. Hey Federico, I've committed some fixes to the branch to make it actually build. After that, I played for 5 minutes with testfilechooser. The general functionality of hiding out-of-root stuff seems to work fine, but the completion in the entry has issues. When rooted to $HOME and /tmp, I found that typing '/' would still complete all toplevel directories, while typing '/t' comes up with no completions. I would have expected just '/tmp' in both cases. Matthias ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: multiroot-filechooser ready for merging
On Thu, 2010-10-07 at 07:09 -0400, Matthias Clasen wrote: When rooted to $HOME and /tmp, I found that typing '/' would still complete all toplevel directories, while typing '/t' comes up with no completions. I would have expected just '/tmp' in both cases. Good catch, thanks. I'll take care of this. Thanks for commiting the build fixes! My GTK+ 3 build setup is hosed at the moment, so I couldn't really test it - I just wanted to push the rebased version to safe place. Federico ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: multiroot-filechooser ready for merging
On Thu, 2010-10-07 at 00:28 +0200, Torsten Schoenfeld wrote: G_TYPE_STRV properties don't need annotations, they are handled automatically. But functions like your gtk_file_chooser_set_root_uris need to have annotations to tell gobject-introspection that 'char **roots' is actually a zero-terminated array. gtk_builder_add_objects_from_string in gtk+-3/gtk/gtkbuilder.c is an example with such an annotation. Got it, thanks. Is the list of annotations documented anywhere? The generated docs in library.gnome.org don't seem to have all the stuff from annotationparser.py (which took some code-reading to find) :) Federico ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: multiroot-filechooser ready for merging
On Thu, 2010-10-07 at 09:59 +0100, Bastien Nocera wrote: Then I would play down the security benefits of the features in the documentation... Yeah, good point. The docs as they are just say that you can't go outside the roots, which could mean that the code tries really hard to do that. I'll fix the docs. Federico ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: multiroot-filechooser ready for merging
On 07.10.2010 18:14, Federico Mena Quintero wrote: Is the list of annotations documented anywhere? This is the canonical place, as far as I know: http://live.gnome.org/GObjectIntrospection/Annotations. ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: multiroot-filechooser ready for merging
On Thu, 2010-10-07 at 20:20 +0200, Torsten Schoenfeld wrote: This is the canonical place, as far as I know: http://live.gnome.org/GObjectIntrospection/Annotations. Perfect, thanks! Federico ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
multiroot-filechooser ready for merging
Hi, all,
I've been running Christian Hammond's multiroot-filechooser branch for
about a month now, with zero ill effects. This is not surprising, as no
apps actually use the multirooting functionality yet; what is nice is
that those apps haven't broken yet.
The past discussion is in bug #609886.
I took the original multiroot-filechooser-2-20 branch and rebased it on
top of master, and pushed the result as a new multiroot-filechooser
branch.
This is ready for merging into master, for 3.0.
Here's a quick summary of this branch.
* GtkFileChooser now has a root-uris property. This is a G_TYPE_STRV.
You can now do something like
char **roots = { file:///home/federico,
file:///mnt/corporate-share,
NULL };
gtk_file_chooser_set_root_uris (chooser, roots);
And then the file chooser will only show subpaths of those roots, and
not let you navigate outside of them. This will be useful for lockdown.
Christian uses it in VMware to constrain where files may be picked from
(a VM image or something, I suppose).
* Internally, the local-only flag has been reimplemented in terms of
roots. When you turn on the local-only flag, you are constrained to the
file:/// root - this means essentially the Unix filesystem, not weird
non-native GVFS mounts.
* The path bar, and the file chooser in general, is smart enough not to
let you climb up above the roots. You can't Alt-up if you are in a root
already, and the pathbar doesn't let you scroll further to the left.
* Shortcuts outside the roots are not shown. Generally stuff outside
the roots doesn't appear at all. You can't autocomplete your way out of
the roots by typing in the filename entry.
So, this mail is just to ask for feedback. Is a boxed G_TYPE_STRV
friendly enough to language bindings? Should I merge this now?
Thanks!
Federico
___
gtk-devel-list mailing list
gtk-devel-list@gnome.org
http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: multiroot-filechooser ready for merging
On Wed, 2010-10-06 at 14:06 -0500, Federico Mena Quintero wrote:
Hi, all,
I've been running Christian Hammond's multiroot-filechooser branch for
about a month now, with zero ill effects. This is not surprising, as no
apps actually use the multirooting functionality yet; what is nice is
that those apps haven't broken yet.
The past discussion is in bug #609886.
I took the original multiroot-filechooser-2-20 branch and rebased it on
top of master, and pushed the result as a new multiroot-filechooser
branch.
This is ready for merging into master, for 3.0.
Here's a quick summary of this branch.
* GtkFileChooser now has a root-uris property. This is a G_TYPE_STRV.
You can now do something like
char **roots = { file:///home/federico,
file:///mnt/corporate-share,
NULL };
gtk_file_chooser_set_root_uris (chooser, roots);
And then the file chooser will only show subpaths of those roots, and
not let you navigate outside of them. This will be useful for lockdown.
Christian uses it in VMware to constrain where files may be picked from
(a VM image or something, I suppose).
* Internally, the local-only flag has been reimplemented in terms of
roots. When you turn on the local-only flag, you are constrained to the
file:/// root - this means essentially the Unix filesystem, not weird
non-native GVFS mounts.
* The path bar, and the file chooser in general, is smart enough not to
let you climb up above the roots. You can't Alt-up if you are in a root
already, and the pathbar doesn't let you scroll further to the left.
* Shortcuts outside the roots are not shown. Generally stuff outside
the roots doesn't appear at all. You can't autocomplete your way out of
the roots by typing in the filename entry.
Symbolic links? To both the filesystem itself, and to directories under
~/.gvfs/. Are those blocked as expected?
___
gtk-devel-list mailing list
gtk-devel-list@gnome.org
http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: multiroot-filechooser ready for merging
On 06.10.2010 21:06, Federico Mena Quintero wrote: Is a boxed G_TYPE_STRV friendly enough to language bindings? Yes, I think so. It's pretty common for arguments and properties, so most bindings will be able to deal with it. With proper annotations, gobject-introspection can also represent it. ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: multiroot-filechooser ready for merging
On Wed, 2010-10-06 at 21:01 +0100, Bastien Nocera wrote: Symbolic links? To both the filesystem itself, and to directories under ~/.gvfs/. Are those blocked as expected? Looks like we have different expectations ;) Nope, we don't try to resolve symlinks to see if they point to allowed hierarchies. This is not hard security; it's about simple lockdown, or about letting people implement a pick a file in the USB stick kind of thing. It would be interesting to desensitize symlinks to places outside the roots. I don't have enough brain cycles left today to implement this, but patches welcome, etc. I'm not sure it's worth the effort to resolve stuff inside .gvfs - if you created a mount and if your $HOME is allowed, then I see no reason to block the mount. (If your ~ is not allowed, then *probably* your lockdown scheme is highly weird anyway.) (Since the file chooser now basically has all the is this file allowed machinery internally, it would be interesting to hook it up to a real security system with really enforceable policies. I hereby declare the can of worms opened.) Federico ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: multiroot-filechooser ready for merging
On Wed, 2010-10-06 at 22:32 +0200, Torsten Schoenfeld wrote: Yes, I think so. It's pretty common for arguments and properties, so most bindings will be able to deal with it. With proper annotations, gobject-introspection can also represent it. Excellent. Where are those annotations made? I grepped quickly in the gtk+ sources for other STRV properties, but didn't find anything that looked like an annotation for a automated generator... Federico ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: multiroot-filechooser ready for merging
On 06.10.2010 23:48, Federico Mena Quintero wrote: On Wed, 2010-10-06 at 22:32 +0200, Torsten Schoenfeld wrote: Yes, I think so. It's pretty common for arguments and properties, so most bindings will be able to deal with it. With proper annotations, gobject-introspection can also represent it. Excellent. Where are those annotations made? I grepped quickly in the gtk+ sources for other STRV properties, but didn't find anything that looked like an annotation for a automated generator... G_TYPE_STRV properties don't need annotations, they are handled automatically. But functions like your gtk_file_chooser_set_root_uris need to have annotations to tell gobject-introspection that 'char **roots' is actually a zero-terminated array. gtk_builder_add_objects_from_string in gtk+-3/gtk/gtkbuilder.c is an example with such an annotation. ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
