FAQ Search Today's Posts Mark Forums Read
» Video Reviews

» Linux Archive

Linux-archive is a website aiming to archive linux email lists and to make them easily accessible for linux users/developers.


» Sponsor

» Partners

» Sponsor

Go Back   Linux Archive > Debian > Debian Development

 
 
LinkBack Thread Tools
 
Old 05-15-2010, 12:16 AM
Russ Allbery
 
Default Open then gates

Christoph Anton Mitterer <calestyo@scientia.net> 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
well.

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
present one.

> 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
localhost.

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
recently.

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
direction.

> 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 (rra@debian.org) <http://www.eyrie.org/~eagle/>


--
To UNSUBSCRIBE, email to debian-devel-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
Archive: 87wrv6vx2y.fsf@windlord.stanford.edu">http://lists.debian.org/87wrv6vx2y.fsf@windlord.stanford.edu
 
Old 05-15-2010, 12:55 AM
Christoph Anton Mitterer
 
Default Open then gates

On Fri, 2010-05-14 at 17:16 -0700, Russ Allbery wrote:
> Why do you have this strong of a reaction to this change?
Because it shows - what I consider to be a - trend in Debian recently
that security dying more and more (again, I do not mean the work of the
Security Team).

- Debian does not ship with hardening stuff per default (e.g. kernels
with PaX patches).
Of course all this can be done manually, but I think at least some of
them should be default, and an admin/user should have to actively
disable them (which usually means that he has at least some knowledge of
what he's doing).
But I see that especially things like PaX will yield in many different
opinions about whether this should be included per default or not.

- Many packages ship with configuration that is either really insecure
or that could be at least hardened a lot.
Some examples: sysctl values could be more tightened or there could be
restrictive set of default iptables rules, portmap recently went aways
from the default to bind to loopback only (IIRC), ejabberd generally
opens some erlang control ports which should be blocked by
netfilter, /etc/defaults/nfs-common enables services which are not
required, depending on which NFS version you're using,... etc. etc. (and
no I do not mean to offend or point with the finger on the respective
maitainers).


- Many packages contain code which does things that is questionable from
a security point of view:
1) Some of them download and install data from the web (fonts, sun jdk
doc, firmware, etc.) but do not verify them, therefore bypassing
Debian's great secure apt system
2) Some do this by intention by installing plugins (firefox, josm, etc
etc.) Of course it's probably bad to completely disable this, but the
user is not even warned, that he gets code, which is perhaps completely
unsecured (transmitted) and especially not covered by the security team.


- et cetera


> you must not understand how
> user-private groups work at all
Well I guess I do,...

> and therefore think that they form some
> sort of security vulnerability.
In principle yes,... but
1) Im not sure whether we see all possible side effects and follow-ups
of this. There might be scripts, programs etc. which do not correctly
set their own (secure) unit mask and thus create files which are to
open. This may even apply to system services. Even in upcoming versions.
2) Users may add other user to their own group, thinking that they've
removed group write permissions on all files, where they do not want to
allow this. But new files may be created later where this could be
security critical.
3) I'd generally say, no other user should be every trusted. Never!
E.g. You wouldn't (usually) create firewall rules that blacklist ports
but such rules which whitelists them. The same should apply here, even a
trusted user (which was added to the UPG) should generally not be
trusted but only selectively for certain files.


> 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
> present one.
See above,... I know that these are no concrete rock solid points, but I
guess we just introduce a insecure way of doing something which should
not be done like this.
Personally I'd even say we should choose a default umask of 077.


> 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.
You need for example for fam, where it's fully enough to have it bound
to loopback.
You need it for nfs-common... now you say one probably want's to have it
then listening to all interfaces,... but I can imagine that people
install it just because nfs is such a common thing and they want to have
the manpages in place.


> 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
> localhost.
Of course,...
But maybe on needs NFS, and needs it just a several places, or very
rarely. Such people want to have the packages installed, but perhaps
disable it (portmap) per default and just enable it, when they really
need it?


> 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
> direction.
Yes,.. but why "opening" something which does not need to be "open".
If a user/admin really needs it, he'll see that something does not work,
find out why, and then enables/opens it.... but _only_ if it's really
required.
That's a major idea of shipping hardened configurations, I guess.


> Have you filed bugs?
Mostly,... but sometimes (!), maintainers to not react at all or simply
say a change is not needed (I've tried for example to convince some of
them to not use MD5 but something better, without success).
Sometimes they simply do not want to make things more hardened/secure as
this would "break" things which currently work out of the box (which I
can of course understand to some point).


> Could you point people at some examples?
See the examples I've provided in this mails,... e.g. sysctl hardening,
or the packages download and install unverified stuff issue.
I've started a somewhat larger discussion about that issue on the d-d
list here.



Cheers,
Chris.
 
Old 05-15-2010, 01:23 AM
Christoph Anton Mitterer
 
Default Open then gates

On Sat, 2010-05-15 at 02:55 +0200, Christoph Anton Mitterer wrote:
> - Many packages ship with configuration that is either really insecure
> or that could be at least hardened a lot.
Another nice (IMHO) example are the X.509 that are shipped per default
in several places (Mozilla NSS, ca-certificates).

Per default all of them are enabled... right?
Mozilla recently proved that they are not really able to manage they
cert store.... giving the fact that they even didn't know where a
root-cert came from an how has control over it.

And personally, I really do _not_ trust some of the CAs which are
included/enabled per default.

I guess, some Chinese blogger, should for example definitely disable the
CNNIC root-CA when the log in to their Google/etc Mail account...


Cheers,
Chris.
 
Old 05-15-2010, 01:32 AM
Andreas Marschke
 
Default Open then gates

Am Samstag 15 Mai 2010, 02:55:40 schrieb Christoph Anton Mitterer:
> On Fri, 2010-05-14 at 17:16 -0700, Russ Allbery wrote:
> > Why do you have this strong of a reaction to this change?
>
> Because it shows - what I consider to be a - trend in Debian recently
> that security dying more and more (again, I do not mean the work of the
> Security Team).
>
> - Debian does not ship with hardening stuff per default (e.g. kernels
> with PaX patches).
> Of course all this can be done manually, but I think at least some of
> them should be default, and an admin/user should have to actively
> disable them (which usually means that he has at least some knowledge of
> what he's doing).
> But I see that especially things like PaX will yield in many different
> opinions about whether this should be included per default or not.
>
> - Many packages ship with configuration that is either really insecure
> or that could be at least hardened a lot.
> Some examples: sysctl values could be more tightened or there could be
> restrictive set of default iptables rules, portmap recently went aways
> from the default to bind to loopback only (IIRC), ejabberd generally
> opens some erlang control ports which should be blocked by
> netfilter, /etc/defaults/nfs-common enables services which are not
> required, depending on which NFS version you're using,... etc. etc. (and
> no I do not mean to offend or point with the finger on the respective
> maitainers).
>
>
> - Many packages contain code which does things that is questionable from
> a security point of view:
> 1) Some of them download and install data from the web (fonts, sun jdk
> doc, firmware, etc.) but do not verify them, therefore bypassing
> Debian's great secure apt system
> 2) Some do this by intention by installing plugins (firefox, josm, etc
> etc.) Of course it's probably bad to completely disable this, but the
> user is not even warned, that he gets code, which is perhaps completely
> unsecured (transmitted) and especially not covered by the security team.
>
>
> - et cetera
In that case why dont we as security aware people and people that think that
more hardened defaults should be applied, go out and file bugs against them
providing atomic patches that the maintainer can review and then either apply
or talk back to the person filing the bug why this is not applicable for this
situation.
I know we have a security team in Debian, but sometimes the presence of just
an asorted list of people caring about one issue while the rest of the teams
overlook this area might be more harmfull, than the issues in themselfs.

> > you must not understand how
> > user-private groups work at all
>
> Well I guess I do,...
>
> > and therefore think that they form some
> >
> > sort of security vulnerability.
>
> In principle yes,... but
> 1) Im not sure whether we see all possible side effects and follow-ups
> of this. There might be scripts, programs etc. which do not correctly
> set their own (secure) unit mask and thus create files which are to
> open. This may even apply to system services. Even in upcoming versions.
> 2) Users may add other user to their own group, thinking that they've
> removed group write permissions on all files, where they do not want to
> allow this. But new files may be created later where this could be
> security critical.
> 3) I'd generally say, no other user should be every trusted. Never!
> E.g. You wouldn't (usually) create firewall rules that blacklist ports
> but such rules which whitelists them. The same should apply here, even a
> trusted user (which was added to the UPG) should generally not be
> trusted but only selectively for certain files.
+1
> > 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 present one.
>
> See above,... I know that these are no concrete rock solid points, but I
> guess we just introduce a insecure way of doing something which should
> not be done like this.
> Personally I'd even say we should choose a default umask of 077.
>
> > 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.
>
> You need for example for fam, where it's fully enough to have it bound
> to loopback.
> You need it for nfs-common... now you say one probably want's to have it
> then listening to all interfaces,... but I can imagine that people
> install it just because nfs is such a common thing and they want to have
> the manpages in place.
>
> > 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
> > localhost.
>
> Of course,...
> But maybe on needs NFS, and needs it just a several places, or very
> rarely. Such people want to have the packages installed, but perhaps
> disable it (portmap) per default and just enable it, when they really
> need it?
>
> > 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 direction.
>
> Yes,.. but why "opening" something which does not need to be "open".
> If a user/admin really needs it, he'll see that something does not work,
> find out why, and then enables/opens it.... but _only_ if it's really
> required.
> That's a major idea of shipping hardened configurations, I guess.

> > Have you filed bugs?
>
> Mostly,... but sometimes (!), maintainers to not react at all or simply
> say a change is not needed (I've tried for example to convince some of
> them to not use MD5 but something better, without success).
> Sometimes they simply do not want to make things more hardened/secure as
> this would "break" things which currently work out of the box (which I
> can of course understand to some point).
Thats sad and a shame.
> > Could you point people at some examples?
>
> See the examples I've provided in this mails,... e.g. sysctl hardening,
> or the packages download and install unverified stuff issue.
> I've started a somewhat larger discussion about that issue on the d-d
> list here.
>
>
>
> Cheers,
> Chris.


--
To UNSUBSCRIBE, email to debian-devel-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
Archive: 201005150332.28405.xxtjaxx@gmail.com">http://lists.debian.org/201005150332.28405.xxtjaxx@gmail.com
 
Old 05-15-2010, 01:39 AM
Christoph Anton Mitterer
 
Default Open then gates

On Sat, 2010-05-15 at 03:32 +0200, Andreas Marschke wrote:
> In that case why dont we as security aware people and people that think that
> more hardened defaults should be applied,
I think we (Debian as a collective) does apparently not think so, which
is probably _not_ specifically proven by that umask002 issue, but many
others.


> go out and file bugs against them
> providing atomic patches that the maintainer can review and then either apply
> or talk back to the person filing the bug why this is not applicable for this
> situation.
See below in my previous mail...


> I know we have a security team in Debian
I guess the security team cannot do much here, expect a package would
ship really extremely dangerously "open" configuration.
But as our project leader wrote in just a few mails ago:
Such "technical" details are under the aegis of the maintainer.



Cheers,
Chris.
 
Old 05-15-2010, 05:22 AM
Russ Allbery
 
Default Open then gates

Christoph Anton Mitterer <calestyo@scientia.net> writes:

> - Many packages contain code which does things that is questionable from
> a security point of view:

> 1) Some of them download and install data from the web (fonts, sun jdk
> doc, firmware, etc.) but do not verify them, therefore bypassing
> Debian's great secure apt system

> 2) Some do this by intention by installing plugins (firefox, josm, etc
> etc.) Of course it's probably bad to completely disable this, but the
> user is not even warned, that he gets code, which is perhaps completely
> unsecured (transmitted) and especially not covered by the security team.

These are really odd complaints to bring against Debian given that these
are not Debian issues. Firefox, for example, works exactly the same way
everywhere. What do you want Debian to do, write our own web browser?
There are limits to what a distribution can do.

>> you must not understand how user-private groups work at all

> Well I guess I do,...

Given your complaints, actually, you don't appear to.

>> and therefore think that they form some sort of security vulnerability.

> In principle yes,... but

> 1) Im not sure whether we see all possible side effects and follow-ups
> of this. There might be scripts, programs etc. which do not correctly
> set their own (secure) unit mask and thus create files which are to
> open. This may even apply to system services. Even in upcoming
> versions.

For example, here, you don't appear to understand that we're talking about
the user umask, which should not be affecting system services, and that
with the existence of user-private groups, creating files with mode 664
(outside of setgid directories) is exactly as locked down as creating
files with mode 644 without user-private groups. That's the whole point
of having them.

> 2) Users may add other user to their own group, thinking that they've
> removed group write permissions on all files, where they do not want to
> allow this. But new files may be created later where this could be
> security critical.

If regular users can add other people to groups on your system, you have
way more serious security problems than user-private groups, and those
security problems are not created by Debian.

> 3) I'd generally say, no other user should be every trusted. Never!
> E.g. You wouldn't (usually) create firewall rules that blacklist ports
> but such rules which whitelists them. The same should apply here, even a
> trusted user (which was added to the UPG) should generally not be
> trusted but only selectively for certain files.

And here, you appear to have completely misunderstood the purpose of
user-private groups in exactly the way that I tried to explain earlier.
If there is anyone in a user-private group other than the user
corresponding to it, you have broken user-private groups and created a
security hole on your system. But that's your misconfiguration, not
something Debian did.

So it seems like indeed I was right: you're upset because you don't
understand user-private groups and don't know how they work.

> Personally I'd even say we should choose a default umask of 077.

There are a lot of arguments for that, and a lot of arguments against it.
That's well-established to be something that people are not going to agree
on, and every distribution picks something and leaves that to site policy,
rightfully. 022 is the "standard" default choice, and I think it's more
appropriate for a free software distribution, although I know that by
itself is a moderately controversial statement.

I'm paranoid by profession, and I'm still in the 022 camp, so I don't
think this is a clear-cut decision.

A umask of 002 with UPG is almost completely equivalent to a umask of 022
without UPG.

>> 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.

> You need for example for fam, where it's fully enough to have it bound
> to loopback.

gamin is a superior implementation of the idea of fam for several reasons,
one of them being that it doesn't require portmap at all. If you're
concerned with security, I encourage you to uninstall fam and install
gamin and then stop worrying about this.

> You need it for nfs-common... now you say one probably want's to have it
> then listening to all interfaces,... but I can imagine that people
> install it just because nfs is such a common thing and they want to have
> the manpages in place.

That seems like a rather questionable thing to do and then complain about
the security stance of the distribution.

>> 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 localhost.

> Of course,...

> But maybe on needs NFS, and needs it just a several places, or very
> rarely. Such people want to have the packages installed, but perhaps
> disable it (portmap) per default and just enable it, when they really
> need it?

If you're sophisticated enough to do that, you're sophisticated enough to
configure it to listen only to localhost. It's not like it's hard.

> Mostly,... but sometimes (!), maintainers to not react at all or simply
> say a change is not needed (I've tried for example to convince some of
> them to not use MD5 but something better, without success).

You do realize that MD5 is still secure against preimage attacks and
replacing MD5 in an existing protocol (as opposed to when designing a new
protocol) is only warranted if you're anticipating a collision attack or
if it's a fairly trivial amount of work, right?

--
Russ Allbery (rra@debian.org) <http://www.eyrie.org/~eagle/>


--
To UNSUBSCRIBE, email to debian-devel-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
Archive: 87sk5tzqmb.fsf@windlord.stanford.edu">http://lists.debian.org/87sk5tzqmb.fsf@windlord.stanford.edu
 
Old 05-15-2010, 05:24 AM
Russ Allbery
 
Default Open then gates

Christoph Anton Mitterer <calestyo@scientia.net> writes:

> Another nice (IMHO) example are the X.509 that are shipped per default
> in several places (Mozilla NSS, ca-certificates).

> Per default all of them are enabled... right?
> Mozilla recently proved that they are not really able to manage they
> cert store.... giving the fact that they even didn't know where a
> root-cert came from an how has control over it.

> And personally, I really do _not_ trust some of the CAs which are
> included/enabled per default.

Having done business with several of them, I don't trust any commercial
CA. This is a way more fundamental problem. Essentially no X.509 used on
the Internet uses trustworthy CAs. X.509 for web authentication is, in
practice, not an authentication mechanism. It's solely an encryption
mechanism. It's almost trivial to bypass the authentication portion if
you're familiar with the business practices of the CAs.

Again, this is really not a Debian problem. To require secure CAs, we'd
have to essentially disable SSL browsing for our users by default. There
is no widely used Linux distribution on earth that's going to make that
choice.

--
Russ Allbery (rra@debian.org) <http://www.eyrie.org/~eagle/>


--
To UNSUBSCRIBE, email to debian-devel-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
Archive: 87ocghzqic.fsf@windlord.stanford.edu">http://lists.debian.org/87ocghzqic.fsf@windlord.stanford.edu
 
Old 05-15-2010, 05:27 AM
Aaron Toponce
 
Default Open then gates

On 05/14/2010 06:40 PM, Klaus Ethgen wrote:
> Oh, I will not make any more comment to that decision. Maybe I will
> search for a more secure distribution. This decision is much to much.
> And it is the last straw that breaks the camels back. Debian was was my
> favorite distribution for over ten years now but in the last time the
> concessions to colourful systems where user simplification goes over
> security is the wrong way.

If you think that changing the default umask to 0002 for user private
groups is compromising security, you don't understand the change, nor
the system its implemented upon. If you have questions about UPG, or
umask, feel free to ask. We'll try to help clear them up.

> Christoph did say it with the right words, just start to use Windows as
> base for the distribution. Sorry, but this is more and more the picture
> I have of Debian.

No, Christoph was just spreading FUD, as are you. This isn't about
Ubuntu, Windows, Mac or any other operating system. It's about correctly
identifying how to increase the functionality of the operating system.
Again, if you truly understood the change...

> Oh, there was technical arguments in the thread. But they was just
> ignored. But there was just one reason to make the umask that more
> insecure, and this is a very special usecase. Compared to the technical
> arguments against the change this has nearly no weight. (I was myself in
> the situation that I had to setup a directory for collaboration work.
> But this didn't need to set the umask of all members to a insecure
> umask.)

You need to explain clearly how the umask of 0002 is insecure. If you
have members in your user private group, then your group isn't private,
is it? UPG is designed to NOT have anyone else in your group except you.
So, adding the write bit on the group mode does not affect security in
the least.

> If they destroy a distribution, yes!

No one is destroying anything. It's rather unfortunate that you don't
understand the argument you're making.

--
. O . O . O . . O O . . . O .
. . O . O O O . O . O O . . O
O O O . O . . O O O O . O O O
 
Old 05-15-2010, 06:41 AM
Christian PERRIER
 
Default Open then gates

Quoting Russ Allbery (rra@debian.org):

> >> you must not understand how user-private groups work at all
>
> > Well I guess I do,...
>
> Given your complaints, actually, you don't appear to.


Is there a mail in this thread that would explain all this?

From your own words, it seems that most negative reactions aboutthis
umask change come from people who misunderstand the concept of UPG.

My own opinion about all this is to be somehow confident that people
much more clever than me when it comes at security are involved in
this and I'm perfectly OK when some people I trust write "002 umask
with UPG is identical to 022 umask without UPG".

Still, I would be able to explain this in case someone asks me such
question in, say, a general talk about Debian where you sometimes find
This Clever Guy Who Understood Everything (and of course never
contributed to any free software work)....and who asks a question
about "why did Debian change its default umask?" or "Why you guys
didn't hang out this OpenSSL maintainer?".

More generally speaking, this umask change probably deserves to be
mentioned in the Release Notes....along with a good rationale about
why, no, this isn't Debian giving up to years of being security-wise.
 
Old 05-15-2010, 07:04 AM
Tollef Fog Heen
 
Default Open then gates

]] Christoph Anton Mitterer

| > 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
| > direction.
|
| Yes,.. but why "opening" something which does not need to be "open".
| If a user/admin really needs it, he'll see that something does not work,
| find out why, and then enables/opens it.... but _only_ if it's really
| required.

You can make that argument for just about all the daemons that are
shipped in the distro. Should ssh not start by default or just listen
to localhost for instance? The admin will notice it's not started and
start it. Ditto for, say, asterisk, should it only listen on loopback?

If you're installing server daemons, I don't see why you expect them to
not listen to network interfaces. If you're uncomfortable with that,
drop an iptables rule on all your systems that sets a default policy of
DROP for incoming and outgoing traffic and just whitelist what you care
about. Anything that's so buggy that it because of security needs to
listen to loopback only by default is IMO so buggy we shouldn't ship it
at all.

Me, I'd rather we stopped shipping /etc/default/* files with ENABLE=NO
and similar silliness – if you want to disable a daemon (or it should
not be enabled by default), put that information into the Default-Start
LSB header or kill the S rcN.d links/make them into K links.

--
Tollef Fog Heen
UNIX is user friendly, it's just picky about who its friends are


--
To UNSUBSCRIBE, email to debian-devel-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
Archive: 87vdap7ij7.fsf@qurzaw.linpro.no">http://lists.debian.org/87vdap7ij7.fsf@qurzaw.linpro.no
 

Thread Tools




All times are GMT. The time now is 07:29 AM.

VBulletin, Copyright ©2000 - 2014, Jelsoft Enterprises Ltd.
Content Relevant URLs by vBSEO ©2007, Crawlability, Inc.
Copyright 2007 - 2008, www.linux-archive.org