Bug 673692

Summary: Must change the firewall to open ports 32768-65535 (?) to allow GNOME nautilus Network browsing of personal file sharing
Product: [Fedora] Fedora Reporter: Wendell Baker <wendellcraigbaker>
Component: gnome-user-shareAssignee: Bastien Nocera <bnocera>
Status: CLOSED DUPLICATE QA Contact: Fedora Extras Quality Assurance <extras-qa>
Severity: unspecified Docs Contact:
Priority: unspecified    
Version: 13CC: bnocera, ccecchi, tbzatek
Target Milestone: ---   
Target Release: ---   
Hardware: Unspecified   
OS: Unspecified   
Whiteboard:
Fixed In Version: Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of: Environment:
Last Closed: 2011-02-07 21:48:41 EST Type: ---
Regression: --- Mount Type: ---
Documentation: --- CRM:
Verified Versions: Category: ---
oVirt Team: --- RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---
Attachments:
Description Flags
the too-cryptic behavior of nautilus when the firewall prevents webdav access to that arbitrary port
none
system-config-firewall settings necessary for GNOME personal file sharing to work
none
GNOME Personal File Sharing is a "Preferences" item and does not require root privileges to enable none

Description Wendell Baker 2011-01-29 15:23:50 EST
Created attachment 475965 [details]
the too-cryptic behavior of nautilus when the firewall prevents webdav access to that arbitrary port

Description of problem:

I'm filing this against nautilus because the effect occurs in nautilus.

Version-Release number of selected component (if applicable):

nautilus-2.30.1-6.fc13.i686

(what gvfs is being used?)
$ rpm -q -a | grep gvfs | sort
gvfs-1.6.2-1.fc13.i686
gvfs-afc-1.6.2-1.fc13.i686
gvfs-archive-1.6.2-1.fc13.i686
gvfs-fuse-1.6.2-1.fc13.i686
gvfs-gphoto2-1.6.2-1.fc13.i686
gvfs-obexftp-1.6.2-1.fc13.i686
gvfs-smb-1.6.2-1.fc13.i686

$ rpm -q -f /usr/libexec/gvfsd-http 
gvfs-1.6.2-1.fc13.i686

$ rpm -q -f /usr/bin/system-config-firewall
system-config-firewall-1.2.27-1.fc13.noarch


How reproducible:

100% deterministic

Steps to Reproduce:
1. Build a Fedora network of multiple machines
2. Use a "standard" wall configuration that only opens a few ports (ssh, mDNS, etc.)
3. Users login to GNOME
4. Users configure Personal File Sharing Preferences (shown)
5. A user (wbaker) uses nautilus to browse the Network and retrieve files from another user's machine (mgbaker).
6. Double-click on the machine icon in nautilus to gvfs mount the webdav personal file share thingy
  
Actual results:

Unable to mount location
HTTP Error: cannot connect to destination
(actuality of the error message shown nearby)

Expected results:

the gvfs webdav mounts

Additional info:

See the screens shots nearby

The problem is that "Personal File Sharing" uses an arbitrary port that is not published ahead of time.   Thus a static firewall configuration can't plan for it.  One can find the port number with avahi-browse or avahi-discover, but it is different for every user on the network.

(exhibiting the diversity of port numbers chosen)

[on suffragette]
$ ps -ef | grep http
wbaker   19530 31865  0 11:21 ?        00:00:00 /usr/sbin/httpd -f /usr/share/gnome-user-share/dav_user_2.2.conf -C Listen 37888
wbaker   21959 19790  0 12:05 pts/10   00:00:00 grep http
wbaker   26676     1  0  2010 ?        00:00:00 /usr/libexec/gvfsd-http --spawner :1.1 /org/gtk/gvfs/exec_spaw/2
wbaker   31865     1  0 Jan23 ?        00:00:06 /usr/sbin/httpd -f /usr/share/gnome-user-share/dav_user_2.2.conf -C Listen 37888
wbaker   31866 31865  0 Jan23 ?        00:00:00 /usr/sbin/httpd -f /usr/share/gnome-user-share/dav_user_2.2.conf -C Listen 37888
wbaker   31867 31865  0 Jan23 ?        00:00:00 /usr/sbin/httpd -f /usr/share/gnome-user-share/dav_user_2.2.conf -C Listen 37888


[on primrose]
$ ps -ef | grep http
mgbaker   3809     1  0 Jan08 ?        00:01:30 /usr/sbin/httpd -f /usr/share/gnome-user-share/dav_user_2.2.conf -C Listen 37778
mgbaker   3813  3809  0 Jan08 ?        00:00:01 /usr/sbin/httpd -f /usr/share/gnome-user-share/dav_user_2.2.conf -C Listen 37778
mgbaker   3818  3809  0 Jan08 ?        00:00:00 /usr/sbin/httpd -f /usr/share/gnome-user-share/dav_user_2.2.conf -C Listen 37778
mgbaker   7348  3809  0 11:30 ?        00:00:00 /usr/sbin/httpd -f /usr/share/gnome-user-share/dav_user_2.2.conf -C Listen 37778


[on pert]
$ ps -ef | grep http
wbaker   12209     1  0 Jan24 ?        00:00:00 /usr/libexec/gvfsd-http --spawner :1.1 /org/gtk/gvfs/exec_spaw/2
wbaker   16040     1  0 12:08 ?        00:00:00 /usr/sbin/httpd -f /usr/share/gnome-user-share/dav_user_2.2.conf -C Listen 38204
wbaker   16041 16040  0 12:08 ?        00:00:00 /usr/sbin/httpd -f /usr/share/gnome-user-share/dav_user_2.2.conf -C Listen 38204
wbaker   16042 16040  0 12:08 ?        00:00:00 /usr/sbin/httpd -f /usr/share/gnome-user-share/dav_user_2.2.conf -C Listen 38204

[on fishnet-effect]
$ ps -ef | grep http
wbaker    1594  1408  0 12:08 pts/0    00:00:00 grep http
wbaker    2850     1  0  2010 ?        00:07:07 /usr/sbin/httpd -f /usr/share/gnome-user-share/dav_user_2.2.conf -C Listen 38155
wbaker    2851  2850  0  2010 ?        00:00:54 /usr/sbin/httpd -f /usr/share/gnome-user-share/dav_user_2.2.conf -C Listen 38155
wbaker    2852  2850  0  2010 ?        00:00:00 /usr/sbin/httpd -f /usr/share/gnome-user-share/dav_user_2.2.conf -C Listen 38155


Remediation:

Open up ports in the high range on the affected machines and hope for the best
There is no "check box" on the system-config-firewall to remind you to "check this to enable GNOME Personal File Sharing"   You just have to know that the high range is probably where these ports are going to be allocated and go for it.  Perhaps there are not other services in the high range that need firewall protection.
Comment 1 Wendell Baker 2011-01-29 15:25:06 EST
Created attachment 475966 [details]
system-config-firewall settings necessary for GNOME personal file sharing to work
Comment 2 Wendell Baker 2011-01-29 15:25:51 EST
Created attachment 475967 [details]
GNOME Personal File Sharing is a "Preferences" item and does not require root privileges to enable
Comment 3 Bastien Nocera 2011-02-07 21:48:41 EST

*** This bug has been marked as a duplicate of bug 179187 ***