7 ms·
I have seldom come across unix multiuser environments getting used anymore for servers. Its generally just one user on one physical machine now a days. I unders
by airocker 2y ago
I have seldom come across unix multiuser environments getting used anymore for servers. Its generally just one user on one physical machine now a days. I understand run0's promise is still useful but i would really like to see the whole unix permission system simplified for just one user who has sudo access.
- unixhero 2y agoThe humans are now spawns of multithread shells and other things. Linux land is still very multiuser oriented. But it is the rise of the mschines instead.
- TZubiri 2y agoaccess management is usually delegated to other systems that supervise UNIX, like AWS
- airocker 2y agoOr Kubernetes. Thats where a standard way of authentication/authorization should be there.
- rpgwaiter 2y agoNixOS may be helping multiuser make a comeback, at least it is for me and my home servers. I no longer have to containerize my apps, i can have one baremetal server with a dozen+ services, all with their own users and permissions, and i don't have to actually think about any of the separation. Plus there’s network shares. Multiple people in my home with linux PCs, each with their own slice of the NFS pie based on user perms. Sure, it’s not secure, but these are people I live with, not state-sponsored hackers. All that said, I’d also love a simpler single-user perm setup. For VMs, containers, etc it would be amazing
- airocker 2y agoNixOS at it again :)
- adastra22 2y agoI’m not sure how “I don’t have to actually think about any of the separation” meshes with the fact that you explicitly setup multiple users and configured file and group permissions accordingly. You clearly put a lot of thought into it. Alternatively, containers really are a no-thinking-required solution. Everything maximally isolated by default.
- oceanplexian 2y agoContainers are isolated but a far, far cry from maximally isolated. They’re still sharing a Linux Kernel with some hand waving and cgroups. The network isolation and QoS side is half-baked even in the most mature implementations. HVM hypervisors were doing stronger, safer, better isolation than Docker was 10 years ago. They are certainly no-thinking required though which leads to the abysmal state of containerized security and performance we have currently.
- airocker 2y agoThere have been no big cves of container escapes for a while now. I guess it can be considered secure enough.
- lyu07282 2y agoA lot of Kernel privescs are also technically container escapes, so 2 months ago was the last one actually: https://www.cvedetails.com/cve/CVE-2024-1086/ https://www.cvedetails.com/cve/CVE-2024-1086/
- airocker 2y agobut then even traditional multi-user would be compromised in this case.
- matrss 2y ago> I’m not sure how “I don’t have to actually think about any of the separation” meshes with the fact that you explicitly setup multiple users and configured file and group permissions accordingly. You clearly put a lot of thought into it. That's the thing, with NixOS you usually don't have to explicitly setup users and permissions. For most simple services, the entire setup is a single line of code in your NixOS configuration. E.g. services.uptime-kuma.enable = true; will make sure that your system is running an uptime-kuma instance, with its own user and all. Some more complex software might require more configuration, but most of the time user and group setup is not part of that.
- tetris11 2y agoDietPi does exactly the same using Debian
- inhumantsar 2y ago> i can have one baremetal server with a dozen+ services, all with their own users and permissions I've used nixos and I don't really see how nixos is special apart from the declarative config. The same can/should be done with any distro and any config manager. And unless you were running Podman in rootless mode, the same setup applies to containers too.
- rpgwaiter 2y agoSure i could do this on debian, but like, i wont. Some software comes packaged with nice scripts to provision new users for running systemd services, but a lot do not. For me and my home network, if the default security mode is “manage users yourself”, i chmod -R 777 on all applicable files and call it a day. Nixos lets me be lazy, as all nixos modules (that I’ve ever used) have their own user setups with minimal permissions by default
- eru 2y agoContainerisation (either with containers or via VMs) doesn't have to be expensive. In principle, you can have just exactly the binary (or binaries) you need in the container or VM, without having a full Linux install. See eg Unikernels like Mirage.
- gnufx 2y agoVisit the research computing environment sometime, for instance. The libzma SSH compromise was considered very worrying, after all.
- richardwhiuk 2y agoThat didn't need multi-users.
- gnufx 2y agoNo, but that's the case I've overwhelmingly seen over the decades. Anyway, are you going to redesign ssh not to require a user, for instance? I assume you wouldn't want sshd running as the putative single user. [I'm all for replacing notions of privileges/permissions with capabilities.]
- richardwhiuk 2y agoYes, i'd rather that the sshd daemon ran with a restricted set of capabilities.
- mbivert 2y agoI've never understood the need for sudo(1) on single-user, physical machines: I keep a root shell (su(1)) around for admin tasks, and it's always been sufficient.
- anon291 2y agoScripting.
- airocker 2y agoIts just maybe easier way to not have to go to the root shell.
- mbivert 2y agoMakes sense (I keep one warm in a tmux, two shortcuts away at most, so it never occurred to me).
- lupusreal 2y agoOne password is easier than two and it feels weird to use the same password for both accounts. About half of my sudo invocations are 'sudo su' lmao.
- bmicraft 2y agoYou could probably save a process with `sudo -i`
- lupusreal 2y agoSlightly less convienent to type.
- MadnessASAP 2y agoYou're entering your own accounts password, not root, when you use sudo. It's a security measure to prove our shell hasn't been hijacked and to make you pause and acknowledge your running a command that may affect the entire system. You can also disable it in the sudoers file.
- anonymous_union 2y agoin some other systems the concept has become overloaded. instead of multiple real people as users, different software with different permissions are different users. its not a bad abstraction.
- airocker 2y agoMaybe containers are a better way of isolating processes as mentioned in other comments.
- deleted 2y ago[deleted]
- berkes 2y agoI always still split up "sysadmin" from "deploy". Ephemeral setups (amongst which k8s) remove that need but introduce a big load of other stuff. Having a VPS that is managed by sysadmins (users with sudo rights, authed with keys) and on which partly overlapping "deploy" users can write to small parts and maybe do a passwordless "sudo sysctl restart fooapp" but only that, is a nice and simple setup. I manage at least seven of these. And nothing in me even considers porting this to my k8s infra. Edit: The reason for this setup is simple and twofold: deploy is safe and clear: deployers can be confident that whatever crap they pull, the server will churn on, data will be safe, recovery is possible. And all devs/ops having their own keys and accts gives a trail, logs and makes it very easy to remove that contractor after she did her work.
- theteapot 2y agoI think you mean systemctl.
- 8372049 2y agoHe probably meant sysadmin as in the account with sudo access.
- BenjiWiebe 2y agos/sysctl/systemctl/
- berkes 2y agoCorrect. Typed it on mobile.
- eru 2y agoYes, we are moving more and more towards a system of immutable deployments. That's good! We don't patch executable binaries these days: we just compile a new one from source, when we made a change. Similarly, more and more we just build new systems (or their images) from source, instead of mucking around with existing systems.
- deleted 2y ago[deleted]
- mbreese 2y ago> across unix multiuser environments getting used anymore for servers I guess it depends on the servers. I'm in academic/research computing and single-user systems are the anomaly. Part of it is having access to beefier systems for smaller slices of time, but most of it is being able to share data and collaboration between users. If you're only used to cloud VMs that are setup for a single user or service, I guess your views would be different.
- shrimp_emoji 2y ago> If you're only used to cloud VMs that are setup for a single user or service, I guess your views would be different. This is overwhelmingly the view for business and personal users. Settings like what you described are very rare nowadays. No corporate IT department is timesharing users on a mainframe. It's just baremetal laptops or VMs on Windows with networked mountpoints.
- mbreese 2y agoMulti-user clusters are still quite common in HPC. And I think you're not going to see a switch away from multi-user systems anytime soon. Single user systems like laptops might be a good use-case, but even the laptop I'm using now has different accounts for me and my wife (and it's a Mac). When you have one OS that is used on devices from phones, to laptops, to servers, to HPC clusters, you're going to have this friction. Could Linux operate in a single-user mode? Of course. But does that really make sense for the other use-cases?
- airocker 2y agoyou could potentially create multiple containers in that machine which are single user and give to every user who needs access. CPU/Memory/GPU can be assigned in any way you want(shared/not shared). Now no user can mess up another user.
- SoftTalker 2y agoIt's not "that machine" it's a cluster of dozens or hundreds of machines that is partitioned in various ways and runs batch jobs submitted via a queuing system (probably slurm).
- NewJazz 2y agoYou only have one admin? How do you know who logged in, ssh certificates?
- airocker 2y agoOnly one human per machine. If you need to share the machine, make multiple containers and give everyone a separate container.
- NewJazz 2y agoYou don't run any services where more than one person shares responsibility for managing that service? E.g. kubernetes. That is just one guy holding it up?
- airocker 2y agoIn an on-prem cluster, yes one guy or a few sysadmins who either share passwords or can somehow put their keys in the authorized keys file and ssh. In the cloud, AWS/GCP let or not let an IAM user reach a server.
- superq 2y agoThat's convenient but doesn't scale and really not too great for security for a bunch of reasons, but it can work great for smaller teams and minimize friction.
- medellin 2y agoSigned ssh certs make your life easy here
- superq 2y agoMaintaining your own PKI isn't exactly easy unless it's your full time job.
- trueismywork 2y agoYou'll just end up implementing multiuser support anyway due to different permissions to different devices services
- airocker 2y agoHow about only in servers where you only have CPU/Memory/disk/GPU with open source trusted drivers?
- jongjong 2y agoTechnically not with virtual machines as the hardware is shared, though I agree, nowadays accounts and access control of the system belong to the virtualization layer below. The benefits of multiple accounts per machine are tiny and not worth the complexity for server setups. We could significantly simplify things by getting rid of the account system. The same could be said for a lot of systems like database servers. Typically it's just one database, one user (your application server) with full access. The account system is mostly an annoyance. For big company use cases where you want to reduce attack surface, why not spawn a second server with different credentials? Anyway big companies typically have many database servers in a cluster and the same credentials are shared by many server processes... The tendency there is literally in the opposite direction.
- zer00eyz 2y ago>> Typically it's just one database, one user (your application server) with full access This is a terrifying way to access databases. Super user, A Modify user (just below super but cant delegate rights) for schema changes. A read/write app user... Probably a pile of read only users who, have audit trails... You might want some admins or analytics users (who have their own scheme additions). The words security and audit trails all spring to mind.
- jongjong 2y agoA simpler solution is to simply not give direct access to the database to anyone who doesn't own a large stake in the project. Expose it via a more restrictive CRUD interface with access control in the application layer.
- bayindirh 2y agoMany, many daemons run under their own users. Just because a single human is using the system, it doesn’t mean the system has a single user. Also, people noted HPC, and other still very relevant scenarios.
- badgersnake 2y agoI haven’t seen it doesn’t mean it doesn’t exist.
- airocker 2y agoExist does not mean it should keep existing if it is unnecessary complexity from the past.
- imtringued 2y agoYou run everything as root or how am I supposed to understand that? Sudo exists to execute commands with a different user. It's an abbreviation of "switch user (then) do" for a reason. Most daemons run under a specific user. Things like docker that use a root Daemon are a security nightmare.
- airocker 2y agoYou dont need to use docker. Containerd or just just direct cgroup manipulation: https://access.redhat.com/documentation/en-us/red_hat_enterprise_linux/6/html/resource_management_guide/sec-creating_cgroups https://access.redhat.com/documentation/en-us/red_hat_enterp...
- blablabla123 2y agoYeah but elevated permissions may be needed from time to time anyway. Either on the client, the baremetal server or the container. Running everything as root is even for containers not recommended. Considering how popular these have become, it's a bit of an irony that systemd isn't available on the container without considerable detours.
- airocker 2y agoOne user with sudo for sysadmins on baremetal and a sudo access without CAP_SYSADMIN on container should be good.
- blablabla123 2y agoI like seeing qmail as blueprint how a secure app that needs elevates permissions should be designed, in fact it has 7 users.
- hobobaggins 2y agoWe use Userify which manages multiple user logins (via SSH) and sudo usage.. there are definitely many, many use cases for teams logging into remote servers, and most security frameworks (PCI-DSS, HIPAA, NIST, ISO 27000) require separate credentials for separate humans. Sudo has some issues, but it works very well and is well understood by many different tools.
- airocker 2y agoIt could all be simplified and map one to one to your identity provider credentials at a higher level. Having a complicated user system on the servers makes it a problem.