Live data from Hacker News

Run0, a systemd based alternative to sudo, announced

mastodon.social

811–820 of 902 posts

Re: Run0, a systemd based alternative to sudo, announced

#811
post #45

systemd has been a net positive for the linux ecosystem. remember when you had to write bash scripts to start, stop, restart services and handle any other signals you want to send it? nowadays it's a unit file (basically just an ini file) away with relatively straightforward API. and you can actually declare startup dependencies and other useful relationships past just "prepend a number signifying when it should run…

> systemd has been a net positive for the linux ecosystem. You're presuming to speak for an awful lot of people there, on a topic that would be difficult to measure. > since the beginning of systemd people have moaned > it's quite annoying that the armchair linux experts complain Now you're overgeneralizing, and doing so in a dismissive and patronizing way. Here are a few examples of problems I have with systemd: Sys…

When it comes to the shutdown issue, I'd argue this is a side-effect of systemd bringing some consistency and correctness to what used to be the wild west, and is highlighting some issue that was before overlooked.

Granted, in a lot of cases the issue probably wasn't a big deal (the system is being shut down, the user is already logged out, do you really care that a system background process is being shut down cleanly?) but from systemd's perspective there's no difference between that and an actually business-critical process that should absolutely be allowed to terminate cleanly before unmounting the filesystem and powering off the machine.

Re: Run0, a systemd based alternative to sudo, announced

#812
post #617

Earlier quoted context omitted.

There have been lots of suggestions for how to improve linux / unix for a very long time. The first great war I remember, and I'm sure there were more before I was around, was DJB vs everyone. For the most part, I think his designs, "weird" as they were / are, are still better than almost every crackpot variation of them that's come since.

Dude you cannot compare DJB to Pottering. DJB is a genius, responsible for all of the non-NSA asymmetric cryptosystems, symmetric cryptosystems, and authenticated encryption algorithms supported by TLS (curve25519, chacha20, Poly1305). He's also the one who got us off of the footgun-by-design, broken-random-number-generator-will-spray-your-privatekey-everywhere nondeterministic nonce signature schemes prior to Ed2551…

What I said was that the first holy war of unix I remember is the DJB vs everyone else.

As far as I can tell, as odd as DJB's designs may have seemed, they were and are ... way better than what was and still hold up today; most of the following "lets unix better" designs seem to just adopt some of DJB's designs, typically poorly.

Systemd certainly seems to have cribbed elements of daemontools et al, but seemingly none of the notion of "least privilege" ...

Re: Run0, a systemd based alternative to sudo, announced

#813
post #741

Earlier quoted context omitted.

run0 has already been exploited: https://twitter.com/hackerfantastic/status/17854955875146385... There will be plenty more where that came from. Yet another terrible idea and terrible implementation from Poettering.

What's the difference between this and ptracing the bash session that you run sudo under?

None, it's a nonsense "hack"

Re: Run0, a systemd based alternative to sudo, announced

#814
post #4

I'm really starting to hate the sub-community in Linux that tries to constantly change it. I don't want to learn a new network config alternative with every update (Ubuntu changed its net config tool again with 24.04). I don't want an immutable os. I don't want to learn to write new config files. I just want to do what I've been doing but with new packages. If there's a problem with something, just fix it. Don't thro…

That's funny. It's like there are two camps, conservatives, and progressives. ;) Jokes aside, I just think that life is constant change and the programming industry is a good example of that. Coding practices have improved a lot in the last few years and will continue to improve with new knowledge and new technology. Sometimes it's better to start anew from scratch than trying to adapt old code into new practices. Bt…

Well, some things are improvements. But many are not, and are just changed for the sake of it.

I'm a fan of SELinux (and the similar mandatory access control on BSD) because it gives strong security but the user or admin keeps control. This is a much better solution than things like immutable OSes where the user can't control anything and just has to trust the developer of the OS.

Re: Run0, a systemd based alternative to sudo, announced

#815

Earlier quoted context omitted.

Capabilities aren't guaranteed to be present, and in a lot of high-security situations aren't available (though obviously you could say that about sudo too)

Sounds exciting and might be obvious, but where will I find systemd and not capabilities?

Containers

Re: Run0, a systemd based alternative to sudo, announced

#816

Earlier quoted context omitted.

you 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.

Isn't that just reinventing multiuser operating systems? Normal Linux already has the property that no user can mess up any other user (unless they are root or have sudo rights)

no it is not

Re: Run0, a systemd based alternative to sudo, announced

#817
post #777

Earlier quoted context omitted.

It 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.

Userify doesn't seem complicated.. it is just Linux users, created with adduser just like you'd type in at the command line: https://github.com/userify/shim/blob/master/shim.py#L227

Seems it uses useradd not adduser

Re: Run0, a systemd based alternative to sudo, announced

#818

Earlier quoted context omitted.

You 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?

In 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.

That'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.

Re: Run0, a systemd based alternative to sudo, announced

#819

Earlier quoted context omitted.

You only have one admin? How do you know who logged in, ssh certificates?

Signed ssh certs make your life easy here

Maintaining your own PKI isn't exactly easy unless it's your full time job.

Re: Run0, a systemd based alternative to sudo, announced

#820
post #687

Earlier quoted context omitted.

The setuid part is where things get exploitable. Pretty much any exploit to date was abusing a library's assumption about what to sideload or what to persist after it got root rights for whatever reason. "Good distro maintainers" (e.g. Arch Linux) try to minimize the attack surface by modifying their packages to use the capabilities flags instead (e.g. the net cap flag for ping binary). "Bad distro maintainers" blame…

Honestly though, elevating privilege is inherently the exploitable part of any program that attempts to cover this space. I would guess you are arguing in a reduction in complexity, which is semi-ironic as run0 is including polkit (and thus: an entire JS interpreter) among other things; while at the same time doas/sudo-rs exist as simpler implementations. AFAIK, lots of the bloat of sudo is preventing a lot of the at…

I agree very lot with what you wrote and I think what annoys me the most is the unpredictability of side effects, where maintainers of libraries push debug environment variables or similar hacks into their production libraries.

As long as this keeps happening due to the concept failure of how shared libraries are used for both active development and runtime execution, there won't be an easy fix available.

The stubborness of C++ developers not seeing that there is two kinds of different users, devs and endusers, is what also annoys me a lot. I understand their intent to make development and debugging easy.

But honestly, that should not be the job of the developer of a library and rather be part of the development toolchain. If the toolchain cannot fulfill this need, then the concept of binary distribution itself (aka FFI/C ABI/ELF) is wrong and needs to change.

The "never change C" mentality is what got us here, where hundreds of developers rewrite everything in Rust/Go/Zig, hoping that there is an end in sight...only to realize that at some point they have to build a different OS from the ground up to actually be able to really fix it.

Post reply on HN