Bug 1580577

Summary: Vino binds to all interfaces when network interface configuration is invalid
Product: Red Hat Enterprise Linux 7 Reporter: Andrew Mike <amike>
Component: vinoAssignee: Ondrej Holy <oholy>
Status: CLOSED ERRATA QA Contact: Desktop QE <desktop-qa-list>
Severity: unspecified Docs Contact:
Priority: unspecified    
Version: 7.5CC: alanm, bmilar, jkoten, jwright, mkolbas, oholy, ovasik, rstrode, tpelka
Target Milestone: rc   
Target Release: ---   
Hardware: x86_64   
OS: Linux   
Whiteboard:
Fixed In Version: vino-3.22.0-7.el7 Doc Type: If docs needed, set a value
Doc Text:
Story Points: ---
Clone Of:
: 1631210 (view as bug list) Environment:
Last Closed: 2018-10-30 10:28:14 UTC Type: Bug
Regression: --- Mount Type: ---
Documentation: --- CRM:
Verified Versions: Category: ---
oVirt Team: --- RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: --- Target Upstream Version:
Embargoed:
Bug Depends On:    
Bug Blocks: 1631210    
Attachments:
Description Flags
Vino dconf key
none
Vino dconf lock file none

Description Andrew Mike 2018-05-21 20:16:17 UTC
Created attachment 1439763 [details]
Vino dconf key

Description of problem: Bugzilla 1211618 indicated that the way to enable Vino starting with RHEL 7.2 was to populate the dconf key "/org/gnome/settings-daemon/plugins/sharing/vino-server/enabled-connections". However, attempts to disable Vino at the system level by locking down the dconf key fail, and vino-server is still enabled when screen sharing is enabled in GNOME Settings.

Version-Release number of selected component (if applicable):\
vino 3.22.0-3.el7.x86_64

How reproducible: Reproducibility appears to be consistent.


Steps to Reproduce:
1. Populate /etc/dconf/db/local.d with the attached vino.key, renaming as needed.
2. Populate /etc/dconf/db/local.d/lock with the attached vino.lock, renaming as needed.
3. Run "dconf reload" as root to reload the dconf database.
4. As a normal user, enter the Vino settings menu (Applications > System Tools > Settings > Sharing > Screen Sharing) and enable screen sharing.
5. Close the screen sharing window.

Actual results: While GNOME Settings shows screen sharing as disabled after closing the screen sharing window, vino-server is still started and binds to 0.0.0.0:5900 and [::]:5900.


Expected results: vino-server does not start at all, or doesn't bind to any interfaces.


Additional info: A few workarounds exist for this issue, but none that disables Vino in a reliable or verifiable way. Ideally, vino should fail to start if 1) it has been configured as disabled by a clear and checkable key, or 2) it has no interfaces it is configured to bind to. Either way, dconf lockdown should be respected.

Comment 2 Andrew Mike 2018-05-21 20:17:05 UTC
Created attachment 1439764 [details]
Vino dconf lock file

Comment 5 Ondrej Holy 2018-05-23 07:13:32 UTC
I've proposed an upstream patch to not listen all if an invalid interface is specified:
https://bugzilla.gnome.org/show_bug.cgi?id=796349

Comment 7 Bohdan Milar 2018-08-23 17:04:43 UTC
I tried to verify the bugfix using a better reproducer:

1. Applications > System Tools > Settings > Sharing > Screen Sharing - disable screen sharing.
2. gsettings set org.gnome.Vino network-interface 'something-wrong'
3. Applications > System Tools > Settings > Sharing > Screen Sharing - enable screen sharing.
4. ss -nlp4 | grep -i vino

Looked OK, i.e. when I used the non-existing 'something-wrong' network interface, vino-3.22.0-6.el7.x86_64 was not listening on any IP (not listed by "ss"), while vino-3.22.0-3.el7.x86_64 listened on "*:5900".

BUT

I had problem to test it on 1 machine, because there was a VM blocking the 5900 port. So I tried to change the default port for vino:

gsettings set org.gnome.Vino alternative-port 5905
gsettings set org.gnome.Vino use-alternative-port true

And ... oops. The fix does not work:

[test@bm-vm-rhel-7 ~]$ rpm -q vino
vino-3.22.0-6.el7.x86_64
[test@bm-vm-rhel-7 ~]$ ss -nlp4
Netid  State      Recv-Q Send-Q             Local Address:Port                            Peer Address:Port              
...
tcp    LISTEN     0      128                            *:22                                         *:*                  
tcp    LISTEN     0      128                    127.0.0.1:631                                        *:*                  
tcp    LISTEN     0      5                              *:5905                                       *:*                   users:(("vino-server",pid=12573,fd=15))

Conclusion: The fix works with the default port (5900) but NOT with alternative ports. I can not verify.

Comment 8 Ondrej Holy 2018-08-27 06:47:28 UTC
Hmm, you are right, it fails in some specific cases. I've reopened the upstream bug report and proposed some additional patches...

Comment 14 Ondrej Holy 2018-09-12 05:11:00 UTC
The new patches have been accepted upstream, so we can go with them...

Comment 17 errata-xmlrpc 2018-10-30 10:28:14 UTC
Since the problem described in this bug report should be
resolved in a recent advisory, it has been closed with a
resolution of ERRATA.

For information on the advisory, and where to find the updated
files, follow the link below.

If the solution does not work for you, open a new bug report.

https://access.redhat.com/errata/RHSA-2018:3140