After an evaluation, GNOME has moved from Bugzilla to GitLab. Learn more about GitLab.
No new issues can be reported in GNOME Bugzilla anymore.
To report an issue in a GNOME project, go to GNOME GitLab.
Do not go to GNOME Gitlab for: Bluefish, Doxygen, GnuCash, GStreamer, java-gnome, LDTP, NetworkManager, Tomboy.
Bug 730789 - Allow disabling network in VMs
Allow disabling network in VMs
Status: RESOLVED OBSOLETE
Product: gnome-boxes
Classification: Applications
Component: general
unspecified
Other All
: Normal enhancement
: 3.22
Assigned To: GNOME Boxes maintainer(s)
GNOME Boxes maintainer(s)
: 754236 780803 (view as bug list)
Depends on:
Blocks:
 
 
Reported: 2014-05-27 07:19 UTC by Lasse Schuirmann
Modified: 2018-01-11 10:08 UTC
See Also:
GNOME target: ---
GNOME version: ---



Description Lasse Schuirmann 2014-05-27 07:19:56 UTC
I noticed that currently Boxes doesn't have the possibility to unshare the network connection.

Since VMs are sometimes intentionaly encapsulated from the environment around them we should allow that.

The primary usecase is the usage of untrusted programs within a trusted network via a VM.
Comment 1 Zeeshan Ali 2014-05-28 18:13:48 UTC
(In reply to comment #0)
> I noticed that currently Boxes doesn't have the possibility to unshare the
> network connection.
> 
> Since VMs are sometimes intentionaly encapsulated from the environment around
> them we should allow that.
> 
> The primary usecase is the usage of untrusted programs within a trusted network
> via a VM.

The network *is* separated from the physical environment since its essentially NAT.
Comment 2 Christophe Fergeau 2014-05-30 09:00:23 UTC
I think this is about totally disabling networking in the VM.
Comment 3 Lasse Schuirmann 2014-05-30 09:01:33 UTC
(In reply to comment #2)
> I think this is about totally disabling networking in the VM.

Yes, thats what I meant.
Comment 4 Zeeshan Ali 2014-05-30 09:59:24 UTC
(In reply to comment #3)
> (In reply to comment #2)
> > I think this is about totally disabling networking in the VM.
> 
> Yes, thats what I meant.

OK, thats different then. :)
Comment 5 Zeeshan Ali 2014-10-18 12:47:12 UTC
Makes sense Jimmac?
Comment 6 Jakub Steiner 2015-05-22 11:20:30 UTC
Exposing the IP in the properties as you described it on IRC makes sense. Not sure about the provided use case for disabling network access. I guess this is to simulate the equivalent of "yanking the cable" for testing purposes, just really making sure the box has no network access...

I'd be looking for this in the properties/system.
Comment 7 Zeeshan Ali 2015-05-22 11:26:12 UTC
(In reply to Jakub Steiner from comment #6)
> Exposing the IP in the properties as you described it on IRC makes sense.
> Not sure about the provided use case for disabling network access. I guess
> this is to simulate the equivalent of "yanking the cable" for testing
> purposes, just really making sure the box has no network access...

Yeah, shouldn't be hard and shouldn't clutter the UI so I'd implement this and bug#744004 together. Just for the record here, my idea is adding this under System tab of properties:

Network [toggle] IP: x.x.x.x
Comment 8 Zeeshan Ali 2015-06-24 17:24:17 UTC
(In reply to Zeeshan Ali (Khattak) from comment #7)
> (In reply to Jakub Steiner from comment #6)
> > Exposing the IP in the properties as you described it on IRC makes sense.
> > Not sure about the provided use case for disabling network access. I guess
> > this is to simulate the equivalent of "yanking the cable" for testing
> > purposes, just really making sure the box has no network access...
> 
> Yeah, shouldn't be hard and shouldn't clutter the UI so I'd implement this
> and bug#744004 together. Just for the record here, my idea is adding this
> under System tab of properties:
> 
> Network [toggle] IP: x.x.x.x

Tried this and failed to make it look good. Also thought more about it and discussed here with David King. The thing is that this can easily be done from within guest (e.g ifconfig eth0 down) so there is no compelling reason for us to provide this from outside the guest. So closing this as INVALID.
Comment 9 Zeeshan Ali 2015-08-28 13:40:56 UTC
*** Bug 754236 has been marked as a duplicate of this bug. ***
Comment 10 Zeeshan Ali 2017-04-07 13:03:27 UTC
*** Bug 780803 has been marked as a duplicate of this bug. ***
Comment 11 Zeeshan Ali 2017-04-07 13:05:12 UTC
Don't remember when and why this was marked as INVALID but I don't see anything in the latest comments about not wanting to do this.
Comment 12 1d28ed33 2017-05-26 14:37:50 UTC
I second this. Target Milestone is 3.22, but I can confirm that v3.22 does not have this feature. This is an essential (& basic) feature for VMs, so please support it.
Comment 13 Zeeshan Ali 2017-05-31 13:28:30 UTC
(In reply to 1d28ed33 from comment #12)
> I second this. Target Milestone is 3.22, but I can confirm that v3.22 does
> not have this feature.

If only one can meet targets. This is not marked as "FIXED".

> This is an essential (& basic) feature for VMs, so
> please support it.

Sure but keep in mind that Boxes team currently consists of only 1 dev who has other responsibilities too.
Comment 14 1d28ed33 2017-05-31 13:37:12 UTC
Oh, okay. Then maybe ramp up the milestone, to show in which version we can expect this feature.
Comment 15 Zeeshan Ali 2017-05-31 13:57:32 UTC
(In reply to 1d28ed33 from comment #14)
> Oh, okay. Then maybe ramp up the milestone, to show in which version we can
> expect this feature.

With the team so slim, you can't plan too far ahead and you'll just end up bumping the milestone after every release for most feature requests.
Comment 16 GNOME Infrastructure Team 2018-01-11 10:08:29 UTC
-- GitLab Migration Automatic Message --

This bug has been migrated to GNOME's GitLab instance and has been closed from further activity.

You can subscribe and participate further through the new bug through this link to our GitLab instance: https://gitlab.gnome.org/GNOME/gnome-boxes/issues/25.