It's incredible to me that sudo has that many LoC. I'd assume it would just ask the OS to execute something without restrictions, not have any logic to do so itself.
Asking the OS to do something without restrictions is not very difficult; sudo does that by virtue of its existence (it's setuid). The extra code is deciding when not to do that.
The problem isn't even setuid exactly but the size of the TCB. Setuid encourages a design in which tons of stuff that doesn't need to run as root runs as root anyway just because it's part of the same binary that needs elevated privileges. It's a footgun, but one can handle even a footgun safely if you practice trigger discipline and assume every gun is loaded.
Sudo (and other setuid programs) could in principle use privilege separation to punt everything not absolutely essential to an unprivileged context and thereby reduce the size of the TCB.
OpenDoas, a portable version of OpenBSD's doas, has 4260 LoC while doing most you'd expect. Sudo just has a lot of policy tools that most don't even know about, but add to its surface area.
sudo has a lot of machinery for representing complex policies which involve partial access to elevated (or just different) permissions, and with more conditions than just a correct password for the requesting user. The kernel itself just sees a binary running as root which may drop some of those permissions before starting another process.
(And this isn't even the most arcane part of linux userland authorization and authentication. PAM is by far the scariest bit, very few people understand it and the underlying architecture is kinda insane)
I think it's all the stuff to do with using a shared sudoers across a network of hosts. They could really clean up the language if they removed all of that gunk, as it's not reflective of how sudo is deployed these days.
Even these days, I don't like having deployment SSH keys, or anything of that nature, unless the users are sudo-restricted. You might say that's obsolete in today's world of kubernetes/clouds, but there are many many use cases not met by these things and even for the clouds, someone needs to run them.
There's also full sudo session logging and a logging server now, along with binaries to replay all those logs. Whether those LOC reflect the logging server, I don't know.
It literally replays in the terminal like a movie. It's nice, but I worry too much about the security implications (passwords captured, etc) to roll it out.
edit:
Ah yes, sudoreplay. You can see this video a playback via it. That's not the guy typing, that's sudoreplay time-accurately replaying what happens.
Should your calculator ask who you are to compute 2+2? Contrary to popular belief, access control was stapled onto the computation space. There was a time when it was considered an unnecessary extravagance. It only became the night unbuckle mandate that machines give a shit about who you are once we started using computers as the basis of business systems.
> It only became […] that machines give a shit about who you are once we started using computers as the basis of business systems.
One we started using connected machines for much and people with flexible though morals noticed that there was trust in the system(s) ripe for exploitation for fun or profit or both.
I remember SMTP hosts being open by default because it wasn't a problem, that very quickly changed once spam was noted as potentially profitable.
There were accounts all over from quite early on, in academic environments before businesses took much of an interest, if only to protect user A from user B's cockups ("rm -rf /home /me/tmp") though to some extent also because compute time was sometimes a billable item, just not on single user designed OSs¹.
[1] Windows, for example, pre NT & 95 (any multi-user features you might have perceived in WfW 3.x were bolted on haphazardly and quite broken WRT actual security)
There is no such API on Linux, it is accomplished by sudo having the setuid bit set, which instructs the kernel to start it as root regardless of the current user. It's probably one of the worst legacy designs still in use - if any binary has setuid set, it runs as root, no questions asked. Conversely, you also have no way of elevating privileges for a running binary. This really should have been solved decades ago with a robust API for authentication and authorisation of running processes to gain and lose privileges, like what Windows has. Having a filesystem bit grant root privileges to a program is insane. There are probably a dozen CVEs waiting to be discovered with silently corrupting the filesystem and setting that bit on your binary.
I tried it and it literally could not last one launch on my phone. The only action that can save me from Instagram is uninstalling the app. I have the web app installed but it's too slow to feed my addiction, so I rarely open it.
Oof, I wonder if this is the reason why I constantly have issues with my M1 Mac connecting to cafe hotspots. Regularly I find places that let me connect and then kick me off less than a minute later.
How many programmers did you need 40 years ago to write MS DOS programs? As you become more productive, more is expected of you. Instead of spending 10 days coloring pixels on the screen, now you're expected to push whole UIs in the same amount of time. Whether this is enabled by high-level languages, tools or AI is irrelevant.
I wonder if we need teams generating dozens of UIs or whatever every day though. There may (or may not) be a limit to how much value-adding work is available to do, or at least diminishing returns that no longer justify high salaries.
YEs we do - your point that there might be too many is valid, but a modern UI when done right is much more accessible to the "common man" than a MSDos and so all the time those teams put in is more than made up for in all the time you saving not having to teach all the people who will use the program and thus we need far more teams than in the MSDos days when we couldn't make a good UI in the first place.
reply