Re: Open then gates
Christoph Anton Mitterer <firstname.lastname@example.org> writes:
> Now that we have Ubuntu as competitor, which is nicely coloured and
> where everything "just works", let's try to imitate (and integrate
> Ubuntu stuff) as much as possible.
> Or even better,... let's use Windows as archetype.
> Why don't we add any user to the root group automatically!? Or even
> better give him/her full sudo rights!? Doesn't the typical desktop
> installation serve just one user anyway?
Why do you have this strong of a reaction to this change? My first
assumption is that, for you to be this upset, you must not understand how
user-private groups work at all and therefore think that they form some
sort of security vulnerability. If that's the case, I'm happy to try to
explain in other ways. It took me some time to understand the concept as
If you have more specific objections other than not understanding the way
they work, I'm afraid you're going to have to be more specific, because we
can't read your mind. I think many people participating in this thread
would be open to being persuaded by a good argument. But you need to
> I've seen so many examples recently, e.g. (IIRC) changing the default
> for portmap back to "bind to any interface".
My personal experience with portmap is that, for most systems, I don't
want it installed at all, and for those systems where I need it installed,
I also need it to respond to public network interfaces because it's there
in order to provide rendezvous service for network services. I appreciate
Debian's committment to allowing portmap to not be installed at all so
that I can purge it completely on most systems. A package that isn't even
installed is better than a package that's installed and listening to
Maybe if you run a lot of NFS client systems, you have a different mix of
issues and end up with a lot of cases where you need portmap but only
listening to localhost?
Also, and I say this as someone who went out of my way to eliminate
portmap from systems for years, I think concerns over the security of
portmap at this point are overblown. Yes, that daemon had a horrible
security track record, but that horrible security track record is about
five years old or more at this point, and it's been reasonably good
Judging from the changelog of portmap, there's been a *lot* of discussion
and angst over this decision over the years, and it wasn't one that was
made easily. I think you're overstating this a bit as an example of a bad
> And I could list dozens of other examples, where packages behave(d) in a
> more or less insecure way or where a rather "open" default configuration
> was chosen.
Have you filed bugs? Could you point people at some examples?
Russ Allbery (email@example.com) <http://www.eyrie.org/~eagle/>