It’s a funny artifact because most people today use, and have only used Linux in a “single user” context. The “local system administrator” is me!
Except if you're on a team of sysadmins running a fleet of systems, either a whole bunch of cattle and/or numerous pets.
There are numerous occasions that I have to SSH to look at something on an individual system, and it's best practice to go in as yourself and then sudo-to-root if you need to poke into privileged parts. App folks can also be allowed in unprivileged and become the service users if needed.
The fact that sudo can hook into LDAP also means we can centralize privilege escalations with groups and (particular) hosts.
Lots of HPC out there as well that is multi-user.
not trying to be rude but this doesn't sound like "most people"
Isn’t Android the most popular Linux distro these days? Probably also most TV set-top boxes and other IoT devices
I understand that I’m not the average user, but then again, nobody really is.
Let the flamewars begin!
On the other hand, I tried to use powershell the other day for some simple admin tasks and ooooh wow I sure don't have anything nice to say.
Also my living is made on the Windows side, and not the Linux side, so I guess I don't know the pain points of WSL.
Generally people aren't running web servers on Windows, but the internal IT infrastructure world uses a ton of Windows servers.
With good reason I'd note, its a use case which windows is profoundly good at - whereas web servers are not something I would say windows is very good at.
All of the Fortune 500 probably does.
Kind regard, Roel (former physicist, developing Android apps (for fun) on my Linux laptop, owner of multiple NAS, but never having been a sysadmin in any company)
> not trying to be rude but this doesn't sound like "most people"
Sure. But sudo still serves a purpose for those folks.
I also use sudo on my macOS system(s) (e.g., MacPorts).
The only ones this message applies are the HPC ones and the "app folks", and the number of ssh-apps that require you to log in another computer is very small nowadays.
Auditing.
> Can you give an example that justifies typing your password up to hundreds of times per day coupled with deliberate hashing delays?
1. I don't do that hundreds of times per day because the stuff I run generally runs pretty well.
2. sudo has password caching, so only the first execution needs a password.
3. If I'm doing a lot, I may sudo-to-root: auditing can still see me going in and becoming root, so it can be determined that I did stuff.
I haven't had a chance to try it out but this is why I think Talos linux (https://www.talos.dev/) is a step in the right direction for Linux as it is used for cloud/servers. Though personally I think multitenancy esp. regarding containerized applications/cgroups is a bigger problem and I don't know if they're addressing that.
Are there some that aren't? Or are you referring here more to untrusted/shared in the sense of platforms like Github Actions just running everyone's different loads on the same pool of kernels?
Why does this matter? Incurring kernel/sandbox boot overhead on cold start/scaling makes it so that services have to over-provision resources to account for potential future resource needs. This wastes a lot of compute. I also think it's incredibly wasteful for companies to manage their own K8s cluster (if K8s supported multitenancy you'd probably want only one instance per-datacenter, and move whatever per-cluster settings people depend on to per-service. This is also much closer to "how Google does things" and why I think Kubernetes sucks to use compared to Borg), again because of all the stranded compute, and also because of the complexity of setting it up and managing it - but without shared-kernel multitenancy, multi-tenant K8s has to employ a lot of complicated workarounds in userspace. Or you can use a serverless product, ie pay for someone else's implementation of those workarounds, and still suffer some of the resource/latency overhead from lack of shared kernel multitenancy.
This is one of the problems I want to address with my company BTW, but it would take years if not decades to get there, which is why I'm starting with something else.
As single user, each and every process has full and complete control of $HOME. Instead, I would prefer all applications were sandboxed to their own little respective areas with minimal access to data unless explicitly authorized. Without going full QubeOS, get some amount of application separation so my photo utility does not have permissions to read ~.ssh.
Create a user account for each application (Firefox, Email, PDFReader, etc). Run each of those applications as the foreign user account. Each application now has its own $HOME with minimal user data. Barring a root-escalation or user-separation bug, the data in your true HOME should be isolated. Even process/environment variable space should be segregated.
This also has a win in that it becomes possible to better segregate the threat model of less trusted applications. Doing granular network permissions per application is a bit hairy in Linux, but it is trivial to fully deny network access to a specific user account.
Not true isolation, but for the semi-trusted development environment, gets you a little something.
I'm referring more to how Linux is used in vast pools of "cattle" servers in Cloud, locally by eg one main user (who doesn't need multi-user but probably still needs some notion of "admin" and per-program permissions), or in a corporate setting (where the actual identity system is managed remotely). This is probably >99% of Linux environments.
I used systemd-nspawn containers https://nixos.wiki/wiki/NixOS_Containers .
For each container I'd run a `filterway` process with a unique app id outside the container and mount the filterway wayland socket inside the container, then wayland programs in the container would just work IIRC (maybe needed to set an environment variable for the wayland socket, or xdg_runtime_dir or something).
I think the wayland compositor itself was running as a user, so I had some setuid commands so that the system bar launch icons could start/stop the containers as the wayland user.
IIRC wayland was pretty flexible, just mounting sockets in various places and making sure permissions were set on the socket worked great.
Some other quick notes: App ids are optional in the wayland spec, but as long as you don't run any such apps in privileged contexts (outside of a container) you can still visually distinguish those. Also IIRC Sway didn't have the ability to vary chrome based on app id - I thought I'd try to indicate the permission level in the task/system bar instead but I think other compositors do have more powerful window decoration rules.
Hyprland has a way to put unique borders per appid too, I think.
> Instead, I would prefer all applications were sandboxed to their own little respective areas with minimal access to data unless explicitly authorized.
I think a pretty useful thing you can do is boot ephemeral instances. So whatever someone does there gets undone. Useful if you’re doing system testing or CI. Because you just set up the machine once and then your scripts and whatever can do what you want. Perfect example is when trying to test install scripts.
Though this is also kinda the point of flatpak and snap. Though these are controversial in the Linux community. Then again a lot it people dislike systemd, though fewer than originally.
Did you have any insight there you might share?
Also occupies like 100kb instead of 40mb because it's C and not go.
It doesn't require forwarding sockets or giving free access to root just for building images. It doesn't explode just because you touch your nftables rules. It doesn't suddenly expose a process to the Internet because of some undocumented option. You can use all the normal tools such as auditd and SELinux without having your configuration overwritten by a madman.
> how it differs from just using Docker
You’re missing the trees for the forest. At a high level they are the same, just as with LXC or podman or others. But it’s the details which are really important. Because your leveraging the system you can really shrink down the size, another user mentioned. But there’s also a convenience in just being able to use systemd when its already built into your system.
I suggest also reading
man systemd-nspawn
I Flatpak wherever I can, but several of my required applications are not first-party packaged, which makes me extra squeamish about installing them.
This is what OpenBSD's unveil does. Firefox for example only has access to ~/Downloads (and some stuff in ~/.mozilla, ~/.config, ~/.cache) in my home directory.
Assuming it does what it says on the tin, and it can work with GUI apps, this would get me almost all the way.
Flatpak does indeed get me part of the way there with better isolation, but available apps seem so scatter shot that I need a fallback mechanism for when there is not an official Flatpak artifact. Distrobox makes a point of indicating they are not a security boundary.
It might even have a github project that people might reach, something like this https://github.com/netblue30/firejail
And it's a bad UX also. As a user, I don't want to deal with fake users, for example.
Users should have never became a security boundary to isolate applications, but they unfortunately have, and there's not really an alternative.
It's not lacking at all. The root + users model is common not only across OSes but also all sort of physical devices.
I didn't claim it does.
> everybody is doing it because they are copying Linux.
This is not true. The model existed decades before Linux.
Doesn't this have to be manually setup. Can i make systemd to run a service under a temporary user automatically.
But anyway, it at least gives them the context on why they're working on these projects to not make containers run as root.
Not so. Multiple users make perfect sense for a household tablet or a gaming PC / console shared between siblings.
Concurrent access is rarely a thing anymore, but serial access is a very common use case.
I personally find it annoying to be forced to use remote identity for devices used by me exclusively, but it makes a lot of sense for shared devices. I'm pretty sure a large portion of people sharing one kind of device would also using be using other devices for the same purpose (eg a kid with divorced parents, a school or office or library with laptops available to be checked out, a tablet used for logistics), so they'd want their data to sync across devices. Handling identity per-device works for local-only files, but also makes it so users need to manually and deliberately configure some kind of syncing if they really do want those files to be available across devices, which to technical people is NBD, but most users aren't technical. It's also just a more secure way to manage data in a corporate setting.
Of course, not every shared device can be expected to always be connected to the internet, some people don't want to back things up remotely for a variety of reasons, and this doesn't matter as much for devices only used by one person. In practice I personally hate how much Microsoft begs and nudges you into this setup even if you're the only one using your computer. But for the majority of users in the majority of cases, remote identity is probably better than local identity, and in the absence of internet it can always fail-open to local identity.
It's much better for users to stick with a solution that's simple enough for non-technical users to have a chance of forming an accurate mental model and and have correct expectations about the availability and safety of their data. But that approach doesn't make it as easy to bundle and upsell subscription services, so that's not the usage model commercial operating systems try to promote.
Not just that but bandwidth constraints as well. Especially upload bandwidth. I might have 1Gb/s down but I have only like 40Mb/s up.
Even if I could make the device file system sparse and pull what it needs on demand, that stuff still needs to get uploaded initially. And on many internet connections, depending on the user content, it could be a while before the whole thing makes it into the cloud.
It is nice having my desktop session just be able to negotiate the permissions with my NAS seamlessly without needing to have a separate user account for the NAS. Same with accessing file shares on any of my devices.
On top of that it's also nice having that same identity work across all of my computers. When I change my password on one computer it is changed on all the computers I use. I never have to think "what was the password for this computer again?" The same account on my gaming PC is the same account on my personal laptop, my main home server, my wife's tablet when I use that, other gaming PC's at friend's houses, etc.
Personally, I really prefer using an IdP in my personal life, especially when its pretty stupid simple to set up and use. It can make a lot of things easier.
And yes, using my Microsoft Account gets me pretty easy access to my NAS. I just grant permissions to MicrosoftAccount\me@hotmail.com and I get permissions. I just set it to MicrosoftAccount\my_wife@outlook.com and it works. I just grant it to MicrosoftAccount\my_friend@gmail.com (Microsoft accounts can be tied to any email) and it works.
I don't really experience much baggage though. Running an LDAP server to do it all comes with far more baggage and management woes for a home deployment. Trust me, I did it for many years before Windows 8+ was widespread. Domain trusts to log into friend's and family's computers with my account was pretty complex to manage and maintain along with actually bothering with site to site VPN connectivity. And when that one friend manages to wipe his forest root without backups...oof.
What NAS, exactly? And how does it handle non-Windows clients?
What you're describing doesn't seem to be something that eg. run of the mill Samba offers, and it's something that Microsoft seems to be changing with every major version of Windows.
> Save for getting access at different locations where there's no VPN connectivity between.
Getting access to what?
A small low power x86 Windows box. Used to be an older gaming PC, swapped for a lower power CPU with integrated graphics. Runs storage for an array, VMs, containers, video transcoding, etc.
Non-Windows clients can also log in with local accounts or with that same MicrosoftAccount realm login username/password. I've used some Pi's and other Linux boxes mounted that way in the past.
But it seems like it's decently well supported in Samba to auth like this though. I'm not sure what happens when their Microsoft account password changes though.
https://forums.unraid.net/topic/117723-allow-at-sign-in-smb-...
> Getting access to what?
Getting access to the LDAP server to handle auth. If I hop on my friend's spare computer at his house, how is it going to reach out to my LDAP server at home?
Same thing when I'm hopping on my dad's computer, or if he wants to use mine when he's visiting. This way we can just use our own logins and have access to our own files, resources, settings, etc. Regardless of whatever computer we're using. If I want him to copy his recent trip photos to the archive when.he comes over he can drag and drop them into the network share on the NAS with his own credentials on his own computer, as I've granted his Microsoft account access to write to the family photos. He doesn't need to remember his password to my NAS, his desktop login is his auth. Same when I'm at a friend's house and on his computer. I just want to pull some big file off my laptop over the network, I can just open up my shares on my laptop and grab whatever. I don't need a separate login to manage.
There's so much stuff that's just so smooth and seamless using an external, managed, widely shared IdP to handle identity management. Some negatives and risks, no doubt. But to me, it's a worthwhile trade off given how easy it makes these kinds of workflows I encounter daily.
We had desktop computers and servers that belonged to the student union, and member students would eventually be granted sudo privileges if they had a reason to need it.
When they gave me and my friends sudo privileges they told us basically the sudo lecture. Use it for good, don’t snoop in other students files, and be careful to not break stuff. They even had a real-life story of their own, about one past member that was kicked out of the union because he had used his sudo privileges to read solutions to an assignment from the home directory of another member!
This wasn’t even that long ago. Around 2010.
It was a nice student union.
1) switch from using "sudo some-command --some-argument" to "some-command --some-argument" in which some-command authenticates and elevates via polkit, and
2) configure polkit to allow the initial human user of the machine to elevate without typing a password.
#2 is just a default, and special configurations can of course override it and return a configuration much like what we have today.
But Jesus Christ Almighty Batman, if I'm installing Ubuntu on my laptop and I, as my regular user, want to install audacity, I shouldn't have to re-enter my password!
Because I'm not sure it's a good idea to not require passwords. At the very least it's a way to make people pause and ask themselves if they really want to give admin rights to whatever program they're running.
Also, you know you can configure sudo to not ask you for a password, right? So why do you need to use a whole new framework and privilege model to basically save yourself from typing four letters?
The whole concept of my personal user account needing to elevate to root to make "system" changes is a relict of long-gone days of BBSes, shell accounts, and time sharing. These days, we should minimize friction between the user (almost always singular) and operation of his system. Apps, not users, should be sandboxed.
I think this is another one of those paradigm shifts accomplished only after a lot of people retire.
What you are advocating for was a disaster for Windows, btw.
No. Maybe have an argument instead of pointing and shrieking?
> What you are advocating for was a disaster for Windows, btw.
No it wasn't. I think UAC is a waste of time, but the type-your-password-into-sudo camp is advocating something strictly worse than UAC.
I don't need to type my god damned password to install a program on iOS or Android.
Maybe make sure there's only a single sudoers entry that applies to your user, and that single entry is NOPASSWD.
1. Install `sudo` via pacman 2. Optionally set the EDITOR env var to use something other than vi for the following command, e.g. `export EDITOR=nvim` (if you do change it and want to retain the default shortcuts like `ctrl+a` to go to the beginning of the line, you'll also probably want to do `set -o emacs` to make sure it doesn't get changed due to the EDITOR being set) 3. Run `sudo visudo` (or `sudo -E visudo` if you want to make sure the `EDITOR` env var is used) to edit the sudoers file and look for the line `%wheel ALL=(ALL:ALL) NOPASSWD: ALL`. Uncomment that one, and comment out the one slightly above that's the same but doesn't have `NOPASSWD`. Save and exit the editor. 4. If you're not already a member of the `wheel` group, add yourself with `usermod -aG wheel <your username>`. You might need to log out and back in or reboot to this to take effect; groups are often weird like that.
As an alternative, Arch has `opendoas` in the `extra` repos nowadays, which is a port of the OpenBSD replacement for sudo designed to be easier to configure. There's literally no configuration for it by default, and to enable passwordless, all you need to put in `/etc/opendoas.conf` is `permit nopass :wheel`.
I may be overgeneralizing, or I may not. I feel like people who hate retyping their passwords (it's most of people) are impatient people apt to take other shortcuts when they can, and therefore can't either be trusted with things like C pointers. Just don't take shortcuts, life's too short for shortcuts.
I retype all my passwords all the time, and I don't let my browsers remember them either. It really doesn't bother me, and a side benefit is, I never forget my passwords.