Finger info for

  1.1 Linux server:

  Mac OS X version:

Other stuff:
  Someone has to explain this to me, because I really don't get it.

  Someone tell me again why I can't bind a port below 1024 on Unix if
  I'm not root? Is there a good reason in this day and age?

  These are the reasons why I suspect the 1024 limit was imposed:

  - Don't let users run system-level services on the mainframe.
  - Don't let the users hog ports for important services on the mainframe.
  - Don't let the users run a bogus service to steal logins on the mainframe.

  ...and here's why I think these aren't relevant anymore:

  - The mainframe is now the desktop. Users can and do run Unix single-user
  now. GNU/Linux's popularity has made Unix a viable desktop system, where
  anyone can have root. TCP/IP's widespread success means that non-Unix
  systems like Windows get full superuser port binding for the desktop
  user, too. The original assumption behind the 1024 limit was that you
  couldn't have root on any available system, even if you wanted it, since
  you didn't own the machine or have physical access to it: the University,
  which paid a mortgage for the system, did. This made it an optimistic,
  albeit immediately practical, security measure.

  - The mainframe isn't even the server any more. Most people aren't using
  a shell account on a big Unix system any more. I grant they still exist;
  I'm typing this in the nano editor on a ssh connection to,
  where about 100 other people also have logins...but the fact that this
  is a .plan file should demonstrate that I dig anachronism. :) Most
  servers are not shell providers. Most people think providing shell
  accounts is really crazy in 2006. Most servers have a handful of admins
  at most, if they use shell accounts at all instead of a "control panel"
  via their web browsers.

  - As for preventing the hogging service ports: my thought is that this was
  never a good idea. The important services started when the server
  started, so if Joe Normal User tried to listen on port 23, the existing
  telnet daemon would already have it bound. Furthermore, you're root, you
  treat this like someone abusing any system resource you need: if you find
  that there's someone using all the system CPU, you kill his process;
  similarly, if you want to run an FTP server, and there's already an FTP
  server bound by a user, you kill it and start your own.

  - As for stealing logins, I refer you again to ubiquitous root access for
  everyone, and root access for no one on the servers that matter. Also,
  the protocols that matter today have had thought put into locking them
  down. Ask anyone that's sent me a panicked email when they see that the
  SSL certificate for is owned by the
  "Ninja Hack Squad" or got OpenSSH's warnings about man-in-the-middle

  ...and here's why it's a problem:
  - There are services that could fall under the arguments protecting ports
  less than 1024 that are on higher ports. MySQL and Subversion pop out at
  me immediately by scrolling through /etc/services. It's a failed policy,
  since there're already more interesting things than there are ports, and
  only more things we haven't dreamed of yet to arrive.
  - There are services you want to run as an end user on your desktop system
  that you don't want to run as root! If I want to use ssh forwarding on
  my desktop Linux box, I can't, unless I bounce off a high port first,
  and hope everything in the system handles that well. If I want to run
  Apache for something on localhost, I have to pick a non-standard port
  and explicitly specify it in Firefox (and hope the web server generates
  links with the non-standard port!). My other option may be to run
  something not-well-trusted under "sudo" when it otherwise didn't need
  root access and doesn't behave well about dropping privs after binding
  a low port.
  - The world has chosen the web. Lots of stuff spits out HTML instead of
  targeting a GUI widget toolkit. Lots of stuff found PHP and Perl and
  Ruby to be clean ways to get cross-platform, multi-user apps written
  quickly, and lots of stuff found that running in one place but being
  accessible to many places made a lot of sense, even if they aren't
  Apache proper. A good example is Unreal Tournament's
  can control the game remotely from a web interface. I don't want to
  run a closed source binary as root just to bind port 80 (and heck, I
  even have the source code to this one!)...there's no other reason to
  run the app as root.

  Fortunately, it's easy enough to fix. Just chop these lines out of
  linux-, around line 433:

  err = -EACCES;
  if (snum && snum < PROT_SOCK && !capable(CAP_NET_BIND_SERVICE))
  goto out; someone send Linus flowers and chocolates and get that changed in
  the mainline kernel. :)

  (ok, there's a capability bit, as you might notice with the capable()
  call up there. I just think it's not worth having at all. Also, you're
  out of luck on other Unixes, I imagine, such as Mac OS X. Also,
  OpenSSH has binding of low ports as non-root disabled always. It's
  hardcoded in the source for most platforms. It's just flatly forbidden
  instead of simply testing if bind() failed.)


When this .plan was written: 2006-08-30 13:28:05
.plan archives for this user are here (RSS here).
Powered by IcculusFinger v2.1.27
Stick it in the camel and go.