Working on debian:604074, I find that there is a confusion between the
usage of "host" vs. "hostname".

I suggest changing the code and the documentation to have a 'host'
directive with a default value of 'localhost'.

Toni, thanks for the report.
Can you more specific about which files have the confusion
and how it can be resolved?

If there is a patch that looks sensible, that I can understand
I can commit the change.

I have attached a patch which will be in my upcoming Debian package.

Okay, so you also change the default value.
What does the os.umask do?

By default, roundup had a umask setting of 0, making all generated files
mode 0666. This was (imho correctly) deemed insecure by the packet
maintainer at the time, and he changed it to 077, so that only the
roundup user, under which the server runs, had access to files generated
by the server (eg. all the mesg* files).

I've tried the patch, but I am unsure about the umask.
IMHO without the patch roundup_server might use the umask of the 
process which is something some people might expect.

Otherwise when testing with python demo.py I could not see a different 
without without adding the chmod command to roundup_server?
Can you give me an example of files which will behave differently after
the change?

Betreff: [Roundup-devel] umask and hostname default with 
roundup-server?
Datum: Freitag, 15. April 2011
Von: Bernhard Reiter <bernhard@intevation.de>
An: roundup-devel@lists.sourceforge.net
Kopie: roundup-users@lists.sourceforge.net

Does anyone rely on the hostname=None default?
Do people conciously set or use the umask for the user that runs 
roundup-server?

I am asking because the suggested patch in 
http://issues.roundup-tracker.org/issue2550693
does wo things:

a) It changes the hostname default to "localhost", which I believe is 
sensible. But I want to know if I need to add something to the 
upgrading 
documentation. I suspect that people are not relying on this.

b) It sets an explicit os.umask(0077) within roundup_server.py.
This would override the umask set for the process before and thus
could make it even less secure. If we need this umask to get a 
different
default I guess we have to make it configurable.
----
As it stands now, I think I'll split out the umask change and apply 
the hostname rectification.

On Fri, Apr 15, 2011 at 09:40:37AM +0200, Bernhard Reiter wrote:
> Does anyone rely on the hostname=None default?
> Do people conciously set or use the umask for the user that runs 
> roundup-server?
> 
> I am asking because the suggested patch in 
> http://issues.roundup-tracker.org/issue2550693
> does wo things:
> 
> a) It changes the hostname default to "localhost", which I believe is 
> sensible. But I want to know if I need to add something to the upgrading 
> documentation. I suspect that people are not relying on this.

As far as I understand the first part of this patch, this changes the
listening behaviour of roundup-server to per default listen only on
localhost.

This seems to follow the (sometimes annoying) behaviour of Debian to
close down the default configuration of all servers to listen only on
localhost. So I don't think I want to apply this in the current form. It
should still be easy to listen on all interfaces (thats what many people
want) and we can discuss if 'localhost' is a sane default (I don't think
the current main use-case of roundup is that all clients access the
server on localhost!). At least that means that almost all users will
either have to add an explicit option to roundup-server or add (and
configure) a server.ini file.

And it breaks the documentation for the option of listening on *all*
network interfaces (which is the current default). First I thought that
it breaks the possibility to listen on all network interfaces but it
probably still works to explicitly configure an empty string for "host"
or explicitly call
roundup-server -h ''
when starting the roundup server. But I don't think we want to have this
new default option because it breaks the default behaviour for most
users.

The new documentation for this option
"If empty, listen on localhost only."
is misleading. If the option is left unconfigured (nothing after the '=')
we have 'localhost'. If the option is explicitly set to an empty string,
we are listening on all interfaces. Not very intuitive to say the least.

So I suggest that Debian ship their default configuration of
roundup-server with this option set to 'localhost' in a debian-specific
server.ini file for roundup-server. The /etc/init.d script for
roundup-server should probably use the -C option to specify a
config-file for roundup-server. This file should probably be located in
/etc/default/roundup-server or so. That way not all users are forced to
upgrade their current installation... and Debian can keep their policy
and make it easy for users to still get a working configuration under
Debian (which does listen on more than localhost :-)

Concerning the doc-consistency fix of that patch, this should definitely
go in...

Ralf
-- 
Dr. Ralf Schlatterbeck                  Tel:   +43/2243/26465-16
Open Source Consulting                  www:   http://www.runtux.com
Reichergasse 131, A-3411 Weidling       email: office@runtux.com
osAlliance member                       email: rsc@osalliance.com

On Fri, Apr 15, 2011 at 12:16:26PM +0200, Toni Mueller wrote:
> On Fri, 15.04.2011 at 09:43:33 +0000, Ralf Schlatterbeck <issues@roundup-tracker.org> wrote:
> > As far as I understand the first part of this patch, this changes the
> > listening behaviour of roundup-server to per default listen only on
> > localhost.
> 
> the documentation in admin_guide.txt always said that roundup will, by
> default, listen only on localhost, but the code listened on all
> interfaces. Also, the guide said that the option was named 'hostname',
> when, in fact, it is named 'host'. So, users were misled to configure
> a non-existent 'hostname' option, that was subsequently being ignored.

OK, so the documentation was never doing what the implementation did.
And the name of the config-option never matched the implementation. But
the help-text of the config-option in the generated .ini file did
correctly describe the behavior.

> > So I don't think I want to apply this in the current form. It
> > should still be easy to listen on all interfaces (thats what many people
> > want) and we can discuss if 'localhost' is a sane default (I don't think
> > the current main use-case of roundup is that all clients access the
> > server on localhost!). At least that means that almost all users will
> > either have to add an explicit option to roundup-server or add (and
> > configure) a server.ini file.
> 
> Yes, it means that all users will have to have a clause in their
> roundup-server.ini. I also agree that the typical roundup user will
> probably not want to listen only on localhost, but then, there may be
> all sorts of front-ending that makes it unneccessary and/or undesirable
> to have roundup listen on all interfaces, anyway. Eg. if you want to
> have SSL and have a reverse proxy to do that for you.

Right. I was arguing for the users that currently have a working
configuration that could break with the change: I've interpreted the
comment in your patch that an empty space in the config-file will now
mean something different (localhost). So we would break lots of working
configurations out there.

But I was misunderstanding the semantics. After your patch an empty
space, i.e., an explicit

host =

will still mean "bind to all IPs". Whereas a *missing* configuration,
i.e.,

#host = 

(or no config-file at all) will then default to localhost.
So my fear that this would break existing configurations is only true
for installations that do not use a .ini file for the server. These will
need an additional "-n ''" parameter to listen on all interfaces
explicitly.

> > And it breaks the documentation for the option of listening on *all*
> > network interfaces (which is the current default).
> 
> I can't seem to find that documentation. In the origiginal
> admin_guide.txt, it says:
> 
> **hostname**
>   Defines the local hostname to listen for clients on. Only required if
>   "localhost" is not sufficient.

roundup-server -S
produces a config.ini which contains:
# Host name of the Roundup web server instance.
# If empty, listen on all network interfaces.
# Default:
host =

Which would change with the proposed patch to:
[...]
If empty, listen on localhost only.
[...]
Which is definitely wrong. If left *unconfigured* it will listen on
localhost. If explicitly configured to empty, it will still listen on
all interfaces. This is the default behaviour of python's socket module.
So I suggest to *not* change the documentation on that config-item, I'm
open for changing the default to localhost, though (and maybe add
0.0.0.0 as suggested by you, the -n option could also use some more
documentation)

> I understand this to mean that the user needs to configure something,
> anyway, if he wants the server to listen on more than localhost.

Currently not.

Umm I was wrong there. See above.

> In one of my roundup-server.ini files, I have the standard
> 
> host = 0.0.0.0
> 
> clause to have the server listen on all interfaces. I should just add
> that as a commented alternative to the shipped .ini file.

Ah, I've never used that alternative. Yes we should document that.

> > So I suggest that Debian ship their default configuration of
> > roundup-server with this option set to 'localhost' in a debian-specific
> > server.ini file for roundup-server. The /etc/init.d script for
> > roundup-server should probably use the -C option to specify a
> > config-file for roundup-server. This file should probably be located in
> > /etc/default/roundup-server or so.
> 
> Nope to all of these. How deep are you into Debian packaging, and why
> do you vent such hostility?

Um, What did you find hostile in that sentence? I can understand if
you've understood my comment about the "(sometimes annoying) behaviour"
of Debian a little hostile. But thats my personal opinion. I'm always
struggling with each new service I install to find out how to get that
particular service to listen to the network. This is unfortunately
different for each service. But let me state that this does not
constitute a hostility to Debian. And being secure by default is still a
good thing. The paragraph above was meant as a suggestion how to proceed
if the patch doesn't not go in as-is. I didn't want to criticise your
work.

Yes. Probably. I did understand the comment to your patch in a way that
suggested that leaving the config-option empty will no longer listen to
the network but will listen to localhost. Thats wrong (see above), so we
won't break existing config files. We will *still* break users having
written their own init.d script or similar that uses no '-n' option. So
the changes should be documented in the upgrading.txt documentation.

Also note that if Debian shipped the release with your original patch,
users would be insecure because they could asume that an empty option
would listen to localhost. That's wrong.

Proposed patch attached.

Ralf
-- 
Dr. Ralf Schlatterbeck                  Tel:   +43/2243/26465-16
Open Source Consulting                  www:   http://www.runtux.com
Reichergasse 131, A-3411 Weidling       email: office@runtux.com
osAlliance member                       email: rsc@osalliance.com

Concerning the second part of this patch (umask) -- this has long ago
ceased to do anything useful (as Bernhard has already observed in his
tests). The reason is that the umask is configurable since 2006-04-27 in
the main roundup.ini config file (not just for roundup-server). The
default is 002 and is debatable. I'm now closing this issue, the main
part (fixing host configuration) is done and the umask is a non-issue.

Toni, Ralf, thanks for taking care of this one.
It looked so easy form the first patch, but I think I did the right
thing in not rushing the issues, the needed analysis toook some time.
Again, thanks Ralf!