On Do, 2014-12-18 at 10:43 -0500, Bastien Nocera wrote:
>
> ----- Original Message -----
> > Hi,
> >
> > > > On the other hand, if you install something and it starts listening and
> > > > you didn’t know that,
> > >
> > > If you install something from Fedora and it does that, then it's a bug in
> > > the
> > > application.
> >
> > No. It's you solving your problem with gnome-user-share and declaring
> > the fallout somebody elses problem so you can safely ignore it.
>
> It's in the packaging guidelines that server applications shouldn't auto-start.
> It's not like I'm making this up...
(a) Bugs happen.
(b) There are third party repos.
(c) I might want use+enable the server apps and still have them
reachable in trusted networks only.
> > I want the guests vnc
> > display be reachable in my home networks and not reachable in
> > public networks. Doing it with the firewall works.
>
> You found a use for the firewall that's still running.
Yea, right.
And exactly that's why I think firewall setup should be alot simpler
than it is now. Less zones, better names for them, ability to set them
per network without digging deep into the network config tool.
Problem is gnome takes the opposite direction: Hide the firewall.
> > (2) Heck, even the gnome-user-share UI shows that. Pick "Remote
> > Login", notice that you can NOT select networks for sharing.
>
> This isn't gnome-user-share. It's the sharing panel in the control-center. And it's
> not there because I wasn't sure whether changing the status quo for this was
> 1) necessary 2) how to implement it without breaking the setup for administrators if
> the user can choose to enable/disable the SSH server themselves.
I'd suggest to simply use the firewall. Do you seriously consider to
automatically start/stop ssh as the machine switches networks? What if
the machine has two active network interfaces with different trust
levels.
> I don't see how keeping the status quo for one (system-wide) service necessarily
> invalidates the design decisions done for all the other (user-wide) services.
I've picked just one example. There are alot more system wide services
which are facing the very same problem. mdns & cups are typical for
desktops. Developer workstations might run a git server, also all sorts
of server services (http, sql, gluster, ...) for testing purposes. The
qemu example goes into that category too.
> > Yes, I know why you can't pick networks for ssh. But this IMO clearly
> > shows that the "just don't listen on untrusted networks" as distro-wide
> > policy isn't going to fly.
>
> I'll implement that if it's all it takes for you to admit that, yes, it's actually
> going to fly.
Yes, I'd like to see a reasonable approach for system services. IMHO
that approach is "use the firewall", but you don't wanna go that route.
So, what else can be done when the user switches networks?
(a) start/stop services. Has the disadvantage that they stop listening
on the loopback device too, and for some (qemu for example) it isn't
a reasonable thing to do.
(b) reconfigure services. Have fun implementing that for all the server
services fedora has.
(c) teach all those services to listen on dbus & reconfigure themselves.
Have fun implementing that for all the server services fedora has.
(d) run those services in a sandbox, reconfigure the sandbox. Yea,
might work (don't know enough about sandboxes to say for sure).
(e) something else?
cheers,
Gerd
--
devel mailing list
devel@xxxxxxxxxxxxxxxxxxxxxxx
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
