Bug 179187 - gnome-user-share stymied by firewall
gnome-user-share stymied by firewall
Status: CLOSED WONTFIX
Product: Fedora
Classification: Fedora
Component: gnome-user-share (Show other bugs)
rawhide
All Linux
medium Severity medium
: ---
: ---
Assigned To: Bastien Nocera
: FutureFeature
: 447248 673692 (view as bug list)
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2006-01-27 17:49 EST by Nalin Dahyabhai
Modified: 2014-06-25 11:33 EDT (History)
15 users (show)

See Also:
Fixed In Version:
Doc Type: Enhancement
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2014-06-25 11:33:41 EDT
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)
/sbin/ip6tables-save showing high ports open (912 bytes, application/octet-stream)
2011-12-22 11:33 EST, Wendell Baker
no flags Details
/sbin/iptables-save showing high ports open (for completeness; pair with ip6tables) (868 bytes, application/octet-stream)
2011-12-22 11:35 EST, Wendell Baker
no flags Details

  None (edit)
Description Nalin Dahyabhai 2006-01-27 17:49:57 EST
Description of problem:
gnome-user-share seems to be blocked by the default firewall

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

How reproducible:
Always

Steps to Reproduce:
1. Configure a system with the default firewall.
2. Turn on sharing of the ~/Public folder.
3. Use 'ps' to determine which port the httpd process is using to listen.
4. Use "cadaver dav://localhost:PORT/" to connect to the server and poke around.
5. Try to connect using cadaver from another workstation.
  
Actual results:
Could not connect to server: No route to host

Expected results:
Successful connection.
Comment 1 Matthias Clasen 2006-02-15 22:55:25 EST
alex, whats the status of gnome-user-share vs firewalls ?
didn't you do kernel work to fix this ?
Comment 2 Alexander Larsson 2006-02-17 09:37:38 EST
Unfortunately not. That was for smb browsing.
This is an actual service, so we can't really permanently punch through the
firewall for this...
Comment 3 Matthias Clasen 2006-02-21 13:54:01 EST
Alex, what is the plan for fixing this ? Or is there no plan ?
Comment 4 Alexander Larsson 2006-02-22 04:36:34 EST
I can't really think of a possible solution. The port we get is a dynamic high
port. We can't open all such ports, and there is no way to dynamically open a
port in the firewall from the app.
Comment 5 Matthias Clasen 2006-03-01 10:15:07 EST
Then there is no point in keeping this on FC5Target
Comment 6 Alexander Larsson 2006-08-11 08:43:57 EDT
Davidz has some ideas about using selinux to let some specific apps punch open
ports in the firewall. That could work.
Comment 7 Matthias Clasen 2006-09-10 13:25:57 EDT
Moving to FC7Target
Comment 8 Matthias Clasen 2007-04-03 11:11:40 EDT
Nothing is going to happen for FC7 here, unfortunately.
Comment 9 Bug Zapper 2008-05-13 22:04:56 EDT
Changing version to '9' as part of upcoming Fedora 9 GA.
More information and reason for this action is here:
http://fedoraproject.org/wiki/BugZappers/HouseKeeping
Comment 10 Bastien Nocera 2008-05-19 06:07:47 EDT
*** Bug 447248 has been marked as a duplicate of this bug. ***
Comment 11 Bug Zapper 2009-06-09 05:08:50 EDT
This bug appears to have been reported against 'rawhide' during the Fedora 11 development cycle.
Changing version to '11'.

More information and reason for this action is here:
http://fedoraproject.org/wiki/BugZappers/HouseKeeping
Comment 12 Alexey Torkhov 2009-09-27 17:55:52 EDT
Is solution to make gnome-user-share bind to fixed port (or next free one) and open in firewall a bunch of ports starting from it considered to be too insecure?
Comment 13 Michael Monreal 2009-10-19 14:29:14 EDT
I am really wondering about this one... F12 will make the "Personal file sharing" even more prominent in the UI by showing those bars in nautilus (in Downloads and Public) and there is not even a hint telling the user that this does not work at all atm if the firewall is active (which is the case in a default configuration).

I wonder if anyone has even a semi-cool workaround for this, or is anyone just turning off the firewall anyway? Really makes me wonder...
Comment 14 Akshay Dua 2010-02-10 19:23:46 EST
Even disabling the firewall isn't getting it to work in my case. 

(In reply to comment #13)
> I am really wondering about this one... F12 will make the "Personal file
> sharing" even more prominent in the UI by showing those bars in nautilus (in
> Downloads and Public) and there is not even a hint telling the user that this
> does not work at all atm if the firewall is active (which is the case in a
> default configuration).
> 
> I wonder if anyone has even a semi-cool workaround for this, or is anyone just
> turning off the firewall anyway? Really makes me wonder...
Comment 15 Billy Coutsis 2010-02-15 23:13:19 EST
I can second that, Akshay.

I have Fedora 12 (i686, firewall disabled, and yum fully updated, running as VM under VMware Server 2.0.2 on Windows XP Professional SP3 32-bit, Ethernet connected to VMware NAT, hostname "apollo.localdomain").

On the Windows host, I've installed Apple's Bonjour 1.0.106 (Bonjour's port 5353/UDP is open, Internet Explorer version is 8.0.6001.18702).

Bonjour's Internet Explorer add-on can see "apollo" and "HP LaserJet 3055 (30E85D)". When I double-click the LaserJet, I can see its management webpage in IE. When I double-click apollo, I get an IE message "the webpage cannot be found", which seems to be an HTTP 404.

The URL that ends up in the IE Address Bar is "http://apollo.local:37830/" -- when I try opening this address in Firefox 3.6, I get a "404 Not Found".

What can I do to help you diagnose this, Bastien? Please let me know.
Comment 16 Billy Coutsis 2010-02-15 23:15:31 EST
I forgot to mention my Fedora Personal File Sharing settings: I have selected "Share public files on network". I get the same behaviour regardless of whether I have "Require password" as "Never" or the preferred "Always".
Comment 17 Michael Monreal 2010-02-16 06:58:35 EST
Billy, did you try to connect to the share from your desktop machine itself? That should work at least... Not sure if it is supposed to work over a NAT, but if bonjour is working, the rest probably should, too...
Comment 18 Billy Coutsis 2010-02-16 19:12:00 EST
Michael,

I think my NAT comment was misleading: I am indeed connecting directly.

To clarify:

192.168.76.1 windows host
192.168.76.128 apollo fedora guest

There is no NAT between the Windows host and the Fedora guest; they are simply on VMware's NAT interface, meaning that the Fedora guest has NAT access to the Internet through the host.

Another point of clarification: I mentioned a LaserJet in Comment 15; this LaserJet is on the Windows host's Ethernet LAN, which is a different IP subnet to 192.168.76.0/24. I only mention it to illustrate that IE/Bonjour seem to be working fine, and the Personal File Sharing problem is with Fedora.

Thanks,
Billy.
Comment 19 Peter Larsen 2011-01-17 20:22:10 EST
Wow - F14 and this is still an open bug?  Why can't the webdav connecting port either be a fixed port, or can iptables be uPnP enabled so local services can temporarily open ports for sessions?
Comment 20 Bastien Nocera 2011-02-07 21:48:41 EST
*** Bug 673692 has been marked as a duplicate of this bug. ***
Comment 21 Pavel Šimerda (pavlix) 2011-11-27 13:26:57 EST
Fedora 16 is out. What's the current status?
Comment 22 Ben Liblit 2011-11-27 15:46:49 EST
Fedora 16 did not fix this.  The problem remains as originally described five years ago.
Comment 23 Wendell Baker 2011-12-22 11:33:56 EST
Created attachment 549218 [details]
/sbin/ip6tables-save showing high ports open

Solution: modify ip6tables, iptables to allow gnome-user-share to work on a network with firewalls "up"

Here's my workaround ip6tables and iptables.

Reasoning:
- since the high ports bounce around
- since the high ports are communicated over mdns you can't guess them or constraint them
- since no other reasonable service uses the very high ports above 32K
it is fair to open them up widely.

Add the following to ip6tables (and iptables)
-A INPUT -p tcp -m tcp --dport 32768:65535 -j ACCEPT 
-A INPUT -p udp -m udp --dport 32768:65535 -j ACCEPT 

I don't believe that kernel hacking is necessary or appropriate here.
Fundamentally, it's a user experience and user-level debuggability problem

A more complete and intuitive solution up into the experience level to this might involve any or all of the following
(a) a user being able to specify the port somehow in their gnome-file-share-properties
(b) the file sharing is a hash of the user's login added to a base port; e.g. sub port($user) { return 35987 + (md5($user) % 256); }
(c) system-config-firewall having prominent support for enabling user sharing in the firewall by whatever scheme, high port, specific port, port range
(d) nautilus webdav gvfs (?) probing to guess whether the surrounding targets have their "shields up" by examining the mdns records and doing a speculative probe once per [reasonable period]

Any solution that reminds the user what is going on will be helpful. The file sharing feature is kindof neato, but it's got to be far more debuggable when it ceases to work.  Today when it ceases to work the world is silent about its very existence.  As such, the Network panel largely is a "windows thing" because that is what shows up there: the windows machines.
Comment 24 Wendell Baker 2011-12-22 11:35:03 EST
Created attachment 549219 [details]
/sbin/iptables-save showing high ports open (for completeness; pair with ip6tables)
Comment 25 Ben Liblit 2013-04-15 23:26:38 EDT
Relevant upstream feature request to have gnome-user-share ask firewalld to punch temporary holes in the firewall: <https://bugzilla.gnome.org/show_bug.cgi?id=336201>.
Comment 26 Bastien Nocera 2014-06-25 11:33:41 EDT
Will be fixed in the next version of Fedora, see:
http://www.hadess.net/2014/06/firewalls-and-per-network-sharing.html

Note You need to log in before you can comment on or make changes to this bug.