Bug 1580577 - Vino binds to all interfaces when network interface configuration is invalid
Summary: Vino binds to all interfaces when network interface configuration is invalid
Keywords:
Status: CLOSED ERRATA
Alias: None
Product: Red Hat Enterprise Linux 7
Classification: Red Hat
Component: vino
Version: 7.5
Hardware: x86_64
OS: Linux
unspecified
unspecified
Target Milestone: rc
: ---
Assignee: Ondrej Holy
QA Contact: Desktop QE
URL:
Whiteboard:
Depends On:
Blocks: 1631210
TreeView+ depends on / blocked
 
Reported: 2018-05-21 20:16 UTC by Andrew Mike
Modified: 2018-11-07 15:29 UTC (History)
9 users (show)

Fixed In Version: vino-3.22.0-7.el7
Doc Type: If docs needed, set a value
Doc Text:
Clone Of:
: 1631210 (view as bug list)
Environment:
Last Closed: 2018-10-30 10:28:14 UTC
Target Upstream Version:


Attachments (Terms of Use)
Vino dconf key (108 bytes, text/plain)
2018-05-21 20:16 UTC, Andrew Mike
no flags Details
Vino dconf lock file (103 bytes, text/plain)
2018-05-21 20:17 UTC, Andrew Mike
no flags Details


Links
System ID Private Priority Status Summary Last Updated
GNOME Bugzilla 796349 0 None None None 2018-12-20 21:51:37 UTC
Red Hat Bugzilla 1211618 1 None None None 2021-01-20 06:05:38 UTC
Red Hat Product Errata RHSA-2018:3140 0 None None None 2018-10-30 10:29:24 UTC

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


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