| |||||||||||||
LCE: The failure of operating systems and how we can fix itLCE: The failure of operating systems and how we can fix itPosted Nov 24, 2012 14:46 UTC (Sat) by jch (guest, #51929)Parent article: LCE: The failure of operating systems and how we can fix it
> Likewise, should the kernel be able to allow multiple processes to transparently use port 80?
That's pretty much orthogonal to resource usage, isn't it?
The issue here is that IP addresses don't obey the usual permissions model: I can chown a directory, thereby giving a user the right to create files and subdirectories within this particular directory, but I cannot chown an IP address, thereby giving a user the right to bind port 80 on this particular address.
I'd be curious to know if I'm the only person feeling that many of the uses of containers and virtualisation would be avoided if the administrator could chown an IP address (or an interface).
-- jch
(Log in to post comments)
LCE: The failure of operating systems and how we can fix it Posted Nov 24, 2012 18:07 UTC (Sat) by dlang (✭ supporter ✭, #313) [Link]
you can make it so that a normal user can bind to port 80, you can also setup iptables rules so that packets only flow on port 80 (or port 80 at a specific IP address) to and from processes running as a particular user.
it's not as trivial as a chown, but it's possible.
I think you are mixing up the purposes of using containers.
It's not the need to use port 80 that causes you to use containers, it's that so many processes that use port 80 don't play well with each other (very specific version dependencies that conflict) or are not trusted to be well written and so you want to limit the damage that they can do if they run amok (either due to local bugs, or do to external attackers)
containers don't give you as much isolation as full virtualization, but they do give you a lot of isolation (and are improving fairly rapidly), and they do so at a fraction of the overhead (both CPU and memory) of full virtualization.
If you have a very heavy process you are running, you may not notice the overhead of the virtualization, but if you have fairly lightweight processes you are running, the overhead can be very significant.
I'm not just talking about the CPU hit for running in a VM, or the memory hit from each VM having it's own kernel, but also things like the hit from each VM doing it's own memeory management, the hit (both CPU and memory) from each VM needing to run it's own copy of all the basic daemons (systemd/init, syslog, dbus, udev, etc) and so on.
If you are running single digit numbers of VMs on one system, you probably don't care about these overheads, but if you are running dozens to hundreds of VMs on one system, these overheads become very significant.
LCE: The failure of operating systems and how we can fix it Posted Nov 24, 2012 18:59 UTC (Sat) by Cyberax (✭ supporter ✭, #52523) [Link]
> you can make it so that a normal user can bind to port 80, you can also setup iptables rules so that packets only flow on port 80 (or port 80 at a specific IP address) to and from processes running as a particular user.
>it's not as trivial as a chown, but it's possible. How? So far I have tried: 1) Iptables - simply DoesNotWork(tm), particularly for localhost. 2) Redirectors - PITA to setup and often no IPv6 support. 3) Capabilities - no way to make it work with Python scripts or Java apps.
For now I'm using nginx as a full-scale HTTP proxy.
That restriction for <1024 ports is by far the most moronic stupid imbecilic UNIX feature ever invented.
LCE: The failure of operating systems and how we can fix it Posted Nov 24, 2012 19:09 UTC (Sat) by bronson (subscriber, #4806) [Link]
It made sense in the 80s and 90s where the typical Unix host was serving tens to thousands of people and root tended to be trustworthy. No sysadmin wants his users competing to be the first to bind to port 79.
It's true that those days are long gone and it's time for this restriction to disappear.
LCE: The failure of operating systems and how we can fix it Posted Nov 24, 2012 19:13 UTC (Sat) by dlang (✭ supporter ✭, #313) [Link]
I don't have the time to look it up right now, but I remember seeing a /proc entry that removed the <1024 limit.
I agree that in the modern Internet, that really doesn't make sense, but going back, you had trusted admins (not just of your local box, but of the other boxes you were talking to), and in that environment it worked.
so think naive not moronic
remember, these are the same people who think that firewalls are evil because they break the unlimited end-to-end connectivity of the Internet. :-)
LCE: The failure of operating systems and how we can fix it Posted Nov 24, 2012 19:21 UTC (Sat) by Cyberax (✭ supporter ✭, #52523) [Link]
>I don't have the time to look it up right now, but I remember seeing a /proc entry that removed the <1024 limit.
There is no such record (I naively thought so too). You can check the Linux source.
>I agree that in the modern Internet, that really doesn't make sense, but going back, you had trusted admins (not just of your local box, but of the other boxes you were talking to), and in that environment it worked.
>remember, these are the same people who think that firewalls are evil because they break the unlimited end-to-end connectivity of the Internet. :-)
LCE: The failure of operating systems and how we can fix it Posted Nov 24, 2012 19:26 UTC (Sat) by dlang (✭ supporter ✭, #313) [Link]
>> I don't have the time to look it up right now, but I remember seeing a /proc entry that removed the <1024 limit.
> There is no such record (I naively thought so too). You can check the Linux source.
Ok, I thought I remembered seeing it at some point in the past, I may have mixed it up with the ability to bind to IP addresses that aren't on the box <shrug>
I wonder how quickly someone could whip up a patch to add this ;-)
seriously, has this been discussed and rejected, or has nobody bothered to try and submit something like this?
LCE: The failure of operating systems and how we can fix it Posted Nov 24, 2012 19:58 UTC (Sat) by Cyberax (✭ supporter ✭, #52523) [Link]
Yes, I remember that such patch was proposed way back then and rejected. And now it will be further complicated by cgroups/namespaces/whatever.
LCE: The failure of operating systems and how we can fix it Posted Jan 10, 2013 12:03 UTC (Thu) by dps (subscriber, #5725) [Link]
Putting my system admin hat on I want both border *and* host security. There is a lot that makes sense to block at borders because outsiders have no business using them. Servers on the safe side of firewalls often have to have more services configured and are therefore less secure.
If both a border firewall blocks some attack traffic then a security bug on an internal system is not immediately fatal and there is time to fix it before the border firewall's security is breached. If that has not happened that implies nobody worthwhile has tried or you can't detect security breaches.
In an ideal world there would be no need for security because nobody would even think of doing a bad dead. The world has never been that way.
|
|||||||||||||