[cjfd]

Yes, a TCP stack certainly is complex enough to warrant serious automated testing and/or TDD.

The idea of putting the TCP stack in user space is interesting. If one actually could map the memory of the whole device into user space one could maybe have fewer system calls and therefore have better performance.

Also, what I find somewhat irritating about using a linux system is how often one needs to run commands as root (sudo) for common administrative tasks like mounting a disk or stuff like that. Having a user space TCP stack could also decrease the need for that as far as setting up the network is concerned. If the linux machine is single user, as most of them are nowadays, it makes more sense that way, I think.

[rmetzler]

> one needs to run commands as root (sudo) for common administrative tasks like mounting a disk

I would think if you don't do this, an attacker who is able to execute code but is non-root yet could easily elevate permissions by shadowing legitimate pathes and trick root into executing untrusted code.

I'm not a security engineer and just find it interesting, so if my thinking is off, please correct me.

[stefan_]

The whole "map the PCIE device into userspace process memory" thing is called DPDK (https://www.dpdk.org/)

[ay]

And you can combine the two:

https://fd.io/docs/vpp/master/whatisvpp/hoststack.html

And there is a sister project using this tech to get noticeable speed-ups:

https://wiki.fd.io/view/VSAP

Disclaimer: I am involved with the VPP project.

[stingraycharles]

> Having a user space TCP stack could also decrease the need for [root privileges] as far as setting up the network is concerned.

I think it’s important to distinguish between the protocol (TCP) and the hardware device. You would still absolutely need to talk to the device, it’s just that moving a lot of the logic to user space means much less context switching for system calls for the application.

I can imagine on Linux you can talk directly to /dev/eth0 if you would want to (in the same way that you can talk to /dev/sda), and then you would be back at square one regarding root privileges.

[monocasa]

> I can imagine on Linux you can talk directly to /dev/eth0 if you would want to (in the same way that you can talk to /dev/sda), and then you would be back at square one regarding root privileges.

It's a AF_PACKET, SOCK_RAW socket rather than a device file, but yes.

[avinassh]

> The idea of putting the TCP stack in user space is interesting.

Indeed! Julia Evans wrote a really nice post explaining the usecases and benefits - https://jvns.ca/blog/2016/06/30/why-do-we-use-the-linux-kern...

[yakubin]

You don't need to be root to mount disks, when you have udisks installed (which would be almost all distros by default). See udisksctl(1): <https://manpages.debian.org/buster/udisks2/udisksctl.1.en.ht...>

[boomlinde]

There's nothing inherent about Linux which prevents you from running everything as uid 0. If you're fine with every process you run having the same full privileges and shared ownership of everything, you should.

Most machines, at least outside embedded devices, are not like this. They are multi-user systems even when there's only ever one breathing thing at the desk because it offers a degree of separation between the privileges of your daemons, your pid 1, your web browser etc.

[heurisko]

I think the point was that root shouldn’t be required for “common administrative tasks”. The nuclear option of running everything as root doesn’t address this.

[boomlinde]

What the single user is called is a technicality. The logical conclusion is the same: your login account has administrative privileges and processes run by that account have administrative privileges as a consequence.

The point I'm getting at isn't to promote the nuclear option, but suggest that maybe there's a good reason for e.g. a web browser or your word processor to not have the same privileges as a user who can execute "simple administrative tasks" like changing the TCP/IP stack through which all your network traffic passes.

[stingraycharles]

What are the common administrative tasks related to networking that require root for networking? All I can think about is stuff like route tables and dhcp, both of which live at the IP/Ethernet level rather than TCP.

[adrian_b]

Starting any network server process that uses ports under 1000, like most standard protocols (https, http, ssh, smtp, dns, ntp, dhcp etc.), requires root rights on any UNIX-like operating system.

Most personal computers do not need server processes (unless you want to connect remotely to them), but your question was not restricted to them.

[boomlinde]

From a practical point of view, regardless of the scope of the original question, this is the kind of scenario where you'd really want the restriction. More than a simple administrative task it's a dangerous attack vector to allow any user to launch your httpd or DNS.

That being said, check out capabilities(7) in Linux. You can grant an executable the privilege of binding to a low port when run by non-0 uid through setcap. This is a good compromise.

[convolvatron]

this whole 'privledged ports' nonsense is left over from a time where some process on another machine running on a low port was somehow to be trusted - because the person running that process was another administrator, and you can generally trust those guys (as opposed to unwashed users).

that world didn't last very long, and I wish we could vent some of these designs that didn't pass the test of time.

[toast0]

You can adjust the highest priviledged port (at least on FreeBSD). It's convenient to set that to 79 and let regular users listen to http without needing root to listen.

ssh and smtp generally need root to do their job, although maybe you could find a way to deliver mail to users without it. If you want to run user based dns or others, you could set the priviledged port even lower.