if I start it with windows I get the firewall request to open the door, and it works.
If you start it with openSUSE it will not start because the firewall blocks the door. I’m new to linux.
Maybe it’s not the firewall, because if I set it to “inactive”, I get the same error “Could not bind socket. Address and port already in use”. However, the application on Windows 10 works well.
If I use “ss dst 127.0.0.1:80” not have other server active
On Wed, 05 Jun 2019 14:36:03 +0000, systemgvp wrote:
> Last question. If I decide to open the port 81 or XX with public access.
> Where I define this in Yast->Firewall? in Port tabs?
You’d just enter it as a TCP port.
As noted on your question on Facebook, if you run applications that
require a listener on ports < 1024, they need to be started as the root
user. There are ways to change the user after the service has started,
but privileged ports are restricted by the kernel.
I’ve never run into a requirement that applications using a port <1024 have to be started on boot or by root… In fact, I’ve very often started up impromptu nodejs and ruby webservers on port 80 with normal User permissions.
For ports <1024, the main thing to be wary about is that they are commonly used by specific types of applications so if you manually launch an app using these ports there is a stronger possibility of creating a conflict (which is what I assume happened to the @OP based on the error that displayed… An application was already using port 80).
Ports >1024 can also be be more or less “reserved” but their claims are generally less strong and applications themselves are likely less commonly used.
No, that would be a security issue and restricted by the kernel for obvious reasons. As Jim already mentioned, privilege separation can be used, or some-other framework such as autobind or indetd used perhaps. The latter can listen on a privileged socket and hand the socket off to an unprivileged application/process for example.
> I’ve never run into a requirement that applications using a port <1024
> have to be started on boot or by root… In fact, I’ve very often
> started up impromptu nodejs and ruby webservers on port 80 with normal
> User permissions.
I have run into this constantly. It’s built into the Linux kernel:
You can use the CAP_NET_BIND_SERVICE capability to override this
behaviour, but the default for the Linux kernel is to not allow access to
those privileged ports.
It’s always been this way. If you’re running nodejs and ruby webservers
on port 80 without doing anything fancy, then something’s broken. My
guess is that there’s something in the setup that you’re using that
enables it, but that’s not default behaviour.
Not surprisingly,
I’m incorrect here and it’s amazing how I never ran into this after launching small, short-lived webservers for special use many hundreds of times over the years… most likely because these small webservers were never intended for permanent use (hardly ever more than an hour) so didn’t care what port they worked on, and typically they were for Development use which typically required root authentication set up already.
So yes…
As is the case for as long as *NIX has existed root is required for applications to serve on “well known” ports 1-1024.