Bugzilla – Bug 239
web interface refuses to allow port 80
Last modified: 2008-12-18 11:12:53 UTC
under Server Settings -> Network there is an option labeled "Web Server Port Number". trying to change the value of that option to "80" results in an error "New value for Web Server Port Number rejected: Invalid value specified: 80" (yes, while running as root with the ability to bind to low port numbers.) Everyone knows that 80 is the correct "web server port number" for a browser-oriented interface. For what it's worth, changing the value directly in .slimserver.pref does work as expected, but that kind of defeats the purpose of being able to configure from the web interface.
it is by design that the ports are limited to above 1025. however, Slim/Web/Setup.pm, Line 1503 ,'Prefs' => { 'httpport' => { 'validate' => \&validateInt ,'validateArgs' => [1025,65535,undef,1] last line changes to: ,'validateArgs' => [80,65535,undef,1] and this would allow any from 80-65535, setting the port to 65535 if a higher number is entered, and generating an error message of a number less than 80 is entered.
This should probably be marked INVALID ("The problem described is not a bug") if the only-above-1024 limitation is by design...
Why is the port number restricted at all? If the user has the necessary permissions (root) needed to set a low port number, why should slimserver prevent them from doing so? For what it's worth, I'd suggest ... ,'validateArgs' => [1,65535,undef,1] though port 80 is particularly useful for a dedicated box.
port 80 is a common port for web servers like Apache and MS IIS. It is good for internet exposed web servers, designed to deliver content to thw world-at-large, and ones having the proper security to deal with attacks from the world-at-large. Also, many other services are already allocated ports below 1024, which would be in conflict should a user enter any number below 1024 arbitrarily. I expect, this is the reasoning behind the validation, to protect the general user from causing a conflict or leaving themselves open. Slimserver doe not go out of the way to perform ANY security from outside world, as this is not its intended use. Being able to edit the config file is considered an expert task, thus the use of port 80 is still available for those case. This is my guess at the reasoning. I wouldn't think Slim Devices would want to be taking the blame for users who didn't know any better...getting in all sorts of complications due to ignorance of security issues.
I'm not suggesting that port 80 (or any other low numbered port) be default, just possible. A port conflict is still a port conflict, regardless of the port number, and enforcing a high port number has no effect on how secure slimserver is. That said, my humble opinion is that an "are you sure?" confirmation with some text about needing to be root to use low port numbers would be a better solution than an "invalid value" error. But if I'm the only one who seems to care, I wont make a big fuss. If the official slim devices policy is to not deal with the issue, feel free to close this ticket.
one thing worth noting, there is a command-line option that does allow this: --httpport 80 of course, proper rights are needed for it to work. Perhaps the description on an error input could include this information. Or, a new validation for ports that specifically reponds to input on a low port value vs other input that is out of range.
Personally I think there is no value in a software restricting which port I want to run my service. Yes, I agree that by default it would be nice not to use 80, but my god...... this should not be restricted in the software at all, and why limit the usage of the device for people that have a valid reason. Regardless of the possible security FUD that is mentioned.... this needs to be changed and really quickly. I can't use the Squeezebox the way I would like and even recommend this to others.... Most companies/hotels/etc do not allow anything other than TCP 80 to proxy out of their networks. So, with this restriction it is impossible to listen to my streaming music at quite of few places..... very sad. Also, I won't open a new bug (unless it would be helpful), but this is an additional enhancement that is required. Basically.... right now if I want to listen to my streaming music over the Internet (or give out to friends to listen to what I am streaming).... it has to run on the same port that my webserver listens for me to configure playlists, etc...... bad. I would love to see two seperate fields making it possible for me to choose which ports listen for each service... Example: stream media over 80 (only allow that port to reach the strem.mp3 or whatever you can implement) but the webserver for music management only listens on 8080 I should be able to define those listening ports (read: unrestricted!) for each service.... okay, rant over!
its only limited from the web interface to prevent just anyone from changing it to a commonly open port. as I have explained, there is a command-line option. However, thank you for your comments. I'm sure you meant them in the most supportive and helpful way. On a more important note, if you do actually wish you have your enhancement request tracked at all, I would advise creating a NEW report. the effectiveness of this tool is directly related to the clarity and specifics of any given bug/enhancement report.
I have to be honest I just don't understand the stance from a security perspective as well as a making it hard for some of the less advanced users. To me it is just an annoyance! =) To ground my comments with some credibility..... I am a security professional and run a major security open source security project. I am a very paranoid computer user when it comes to securing a product... Lets face it... This is a web service we are talking about... there is nothing wrong with running a web service on 80...... this is not a custom service that needs its own registered port. I 100% agree that the default should not be 80, and agree with Michael that if you just place a nice little warning message or confirm when a user tries to use port 80 that is completely fine and is an improvement for the software. No need to force a user to get on the CLI to make the change... Trying to convince people that Security through Obscurity is the right way to protect your web services does not work.. and will never work in the security industry. Thanks for providing feedback tho.. I really like the product and software and hope that the developers will continue to work on the product/features and take some feedback into consideration! =) Also, I will open a couple new bugs and would love feedback!
I agree, restricting the port value does seem silly, but many operating systems restrict (as a legacy security measure) what software can open what port, including Mac OS X and most other unix software. Windows doesn't make this restriction, (as far as I know) but the built-in web server in windows would conflict. And the built-in firewall would have to be configured as well. Rather than have a hard coded value, we should probably try to open the port and give an error if it fails, thus letting the OS handle conflicts and it's own security policy. Patches welcome.
I also think there should be no port restrictions in the web ui. I run SlimServer on port 80 and was a bit confused by the 'New value for Web Server Port Number rejected' error message shown when I made other changes on the network settings page. Part of that confusion is that this wasn't a new value.
I think this request can be closed. There was a recent discussion regarding this issue in the forums: http://forums.slimdevices.com/showthread.php?t=35483 The gyst of it is: The HTTP interface can be easily run on port 80 on Windows systems, but on *nix systems it would requires running SlimServer as root to be able to listen on any port below 1024. That's not acceptable from a security standpoint. Change 12202 has been checked in to 7.0 that permits setting of any HTTP port on Windows systems, but still rejects those below 1024 on other operating systems. It works now both in the command line option and when entered in the web interface. That seems like a perfect compromise to me. So I recommend setting the target to 7.0 and marking this as fixed.
(In reply to comment #12) > Change 12202 has been checked in to 7.0 that permits setting of any HTTP port > on Windows systems, but still rejects those below 1024 on other operating > systems. It works now both in the command line option and when entered in the > web interface. That seems like a perfect compromise to me. > > So I recommend setting the target to 7.0 and marking this as fixed. > Marking bug as fixed...please reopen and add new comments if you don't feel this bug has been properly addressed in SC 7.x