761–770 of 902 posts
Earlier quoted context omitted.
My last job was at a UK bank. All our *nix systems were configured with a specific whitelist of commands that could be run via sudo. We found this an enormous pain in the arse when the powers that be decided to deploy ansible everywhere, and found that none of its "become" methods would work if sudo was set up like that.
I had a job once which had a sudo whitelist, but vi was included. !sh and you had root.
Earlier quoted context omitted.
There have been no big cves of container escapes for a while now. I guess it can be considered secure enough.
A 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/
Earlier quoted context omitted.
> For how long? Debian switched to systemd about 12 years ago, so at least that long.
A quick google indicates that it was made default in debian 8 in 2015, which is 9 years ago, not 12. Perhaps it was available prior to then, but so were daemontools, upstart, and probably a variety of other alternatives.
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.
You 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.
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.
I haven’t seen it doesn’t mean it doesn’t exist.
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.
Yeah 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.
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.
We 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.
Earlier quoted context omitted.
I can use GNU bash on NetBSD with no other GNU software installed. I can install GNU coreutils on Alpine Linux (complete with musl libc instead of glibc). In fact, it's possible to just install a single part of GNU coreutils but not the rest - ex. Alpine packages just sha512sum as https://pkgs.alpinelinux.org/contents?branch=edge&name=coreu... (not sure why). I don't think I've seen it done, but you could build a Lin…
> and they're all portable... I think that portability is a deliberate anti-goal of systemd. > In contrast, if you want to use, say, run0, you must run systemd as PID 1, No, you must run something on pid 1 that implements the spec, similar to how musl can be used instead of glibc - they both implement the same spec. Run0 expects pid 1 to behave a certain way, much like my web browser expects web servers to behave a c…
Yes, and that is one of the things I dislike about it. (In fairness, the list of things I like about it and the list of things I dislike about it are both fairly long.)
> No, you must run something on pid 1 that implements the spec, similar to how musl can be used instead of glibc - they both implement the same spec.
> Run0 expects pid 1 to behave a certain way, much like my web browser expects web servers to behave a certain way.
If there's only one implementation, then it's not portable. If a webapp uses a web API that only Chrome implements, it's not portable regardless of whether Google published a spec for their non-standard behavior. There are dozens of web servers and web clients that all speak HTTP, there is one systemd.
Earlier quoted context omitted.
I had a job once which had a sudo whitelist, but vi was included. !sh and you had root.
Classic case of #CorporateIT applying white paper "rules" and not understanding what they're doing. If I had a nickel...
Earlier quoted context omitted.
> Mr. Poopering This is childish and petty, I suggest you delete your account.
You can't delete your HN account.